Re: [Gnu-arch-users] tla archives return value

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    > >>>>> "Nathan" == Nathan Tenney <address@hidden> writes:

    >     Nathan> I'm new to arch, and I have to say that this type of thing
    >     Nathan> is what makes the learning curve for arch so steep.  WAY
    >     Nathan> too many commands.

    > This is a problem with the output of "tla help", not with tla.  You
    > don't have to use those commands.

    > Suppose tla help were changed to output only the recommended forms of
    > commands mentioned in the tutorial, unless you gave it an option: "tla
    > help --full".  (I don't know if Tom would sign off on that, though.)

Right (and it's nice that Miles will pick that off).


    >     Nathan> Why do you object to returning a nonzero return value for
    >     Nathan> a search that failed in tla archives?

    > [Not speaking for Tom.]  I think Tom's objection is natural.  One
    > reason is that "tla archives" does a number of things, any of which
    > could fail, in a number of different ways.  Thus you want to be
    > careful about specifying the interface so you don't get in the way of
    > other useful extensions to be proposed later.

    > By defining a new command you get exactly the API desired.

Pretty much.    The particular functionality desired here is also
important to think about:

The goal is to have a command which accepts an archive name and tells
your script whether or not the archive is registered.   Exit status is
a reasonable way to return that data, but how should the parameter
(the archive name) be specified?

`tla archives' accepts a regexp.   That's a winning feature, in my
view -- I use it constantly.    It's  just about the perfect
short-hand for my #1 use of the `archives' command, and it does
something that could not easily be done reliably with grep.

An archive name typically contains the character '.'   It would
probably be a good idea to increase the set of punctuation characters
that can be in an archive name: '+', at least.

'.' and '+' have special meaning in a regexp.

To use `tla archives' to find out, in a script, if a given archive
name is registered, the script would have to:

        1) quote the special characters in the archive name
        2) wrap the archive name in ^ and $

I think that that's unacceptably inconvenient.   Worse still, a script
that does that incorrectly will appear to work just fine in most
cases, and then just flake out down the road somewhere.

So the question then becomes:  should `tla archives' take a new option
that says "this isn't a regexp -- it's a literal archive name," or
should that functionality appear in a separate command?   (Note that a
flag which says "this is a literal, not a regexp" suffers the same bug
with wrong scripts: if a script forgets that flag, it will appear to
work often but will still flake out in some cases.)

There's another question to keep in mind, too.   How can a script
implement:   "Given an archive name, determine its location?"

`tla archives' can do that (with the same quoting problem) but the
output format of `tla archives' is optimized for a human reader, not
for parsing by a trivial script.

A new `tla archive-location' command can kill two birds with one
stone:  providing both an easy way to get an archive's location in a
script, and an easy way to test whether or not an archive is
registered in a script.

The clincher is that the new functionality is of value almost
exclusively in scripts.    Interactively, `tla archives' will just
about always be fine.   (So, why clutter up `tla archives' with new
options that can confuse new users?)

-t