Re: [Gnu-arch-users] Re: minor extension to arch protocol

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Mon, 2003-11-17 at 04:00, Miles Bader wrote:

    > > The only way I can see to solve this is to move the conflicting
    > > namespace (all the alphanumeric dirs) into a subdir, but that would be a
    > > more drastic change.

    > That's exactly what I suggested earlier.   Then we bump the project
    > format version to 2.  


No, it's goofy.   Miles has understated the problem.

There's a very general problem which might be stated this way:

        I have some directory, used as a data structure for
        arch or a related system, in which I want to create
        subdirectories named after categories (or branches or
        versions or archives or revisions).

        That's easy enough to solve:  I simply name the subdirs
        after the category (or branch or ....).

        Now, later, I have a second problem.   I want to attach
        some extra data to that directory.   I want to create
        a new "field" on the data structure, so to speak.

        How do I do that?

The answer is that, in general, I pick a name for the new field that
doesn't clash with a valid arch category (or whatever) name.

Simple.  Effective.

Moving all the category subdirs to a nested subdirectory doesn't solve
the problem.  It just pushes the same problem one level deeper.

Then some people come along and say "Oh, you picked the name =foo.
That messes up the version of sh that I use.  Please change it."

And you say in reply "Hmm.  Looking at the standard, it seems that '='
as a filename prefix can't possibly be confused with a shell
meta-character except if the filename in question is an executable
being used in the command name position of a shell expression.  This
file isn't an executable.  I think your shell is broken."

And then they say, "Oh, please.   We're not free to fix the shell.
It would be much better if you compound the problem."

So then you tell them stories about the history of completion in bash
and how that history effected people designing things like zsh and
what it was like to use tops-20 and how the itla framework is a much
better idea anyway.

And then if history is any indication, you get flamed for "imposing
policy" or adopting bad tone or being otherwise recalcitrant to the
needs of users when, really, you're just trying to help them see more
clearly what you think their real needs are.

And then you become filled with self doubt.  "Perhaps I'm just being
stubborn?" you might think.  So you think about it a while.  And then
think some more.  You think about the consequences of "compounding the
error".  You think about all the stern and frightening stories
justifying engineering stubbornness (and humility) that were a
prominent part of your experience as an engineering student.  You try
to weight it on that scale.  You think about patches floating around
that would fix this instance of bash's completion breakage.  You think
about "~~" being a more reasonable alternative to "=" as zsh uses it.

And so you just take to repeating yourself but at least trying to mix
up the style in the hopes that some expression of the issues will 
actually be clearer than the earlier ones you tried.

At least that's been my experience.


"Every litter bit hurts" -- slogan on public trash cans in some cities 
and a good thing to keep in mind when contemplating compounding an
error made by 2-3 programs.
-t