RE: PATCH: Re: sudo completion problem

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

> Andrej Borsenkow wrote:
> >I think, it was the result of change for find (do not have article
> >handy) - in ``find /tmp -user'' -user was not recognised as option
> >because /tmp already was argument. So, this change made
> options be found
> >everywhere, even after arguments :-)
>
> That's the wrong way to do it.  In the find command line,
> `-user' is not
> an option, it's an expression (or part thereof).  The
> expression starts
> with the first argument that starts with `-' and continues to the end
> of the line; the directory arguments must appear before the
> expression.
> Actual options are handled as dummy predicates, which is confusing to
> the user, but from our point of view means that they must be
> treated as
> part of the expression.
>


I was about to suggest, that it still doable with _arguments - but then
realised, that there is no way to describe "structured arguments" or
"argument values". Every argument is treated as an independent word and
moreover, there is no way to "name" arguments at all.

So, the question is - how useful would it be to allow "named,
structured, ..." arguments? The point is, description vs. shell code.
Basically, be able to treat arguments in almost the same way as
options - with some separator in between. In this case, we could still
use _arguments for find - actually, it does it quite well currently, and
it is a pity to reinvent the wheel.

This may be useful in other cases as well. cvs comes in mind
immediately - common options, then checkout, update, etc as argument -
and possibly (sub-)options and (sub-)arguments for every of them.

I understand, that this is hierarchical structure that probably cannot
be handled with one single table ... but, just as idea, imagine that
action for `update' argument simply points to subarguments description
... or something like this ... this may be more readable than shell
functions. May be not. But it is easier in cases, where we need several
versions for different plattforms.

Then I realised, that reverse situation exists with options - there is
no way to describe options without - prefix. Consider dd or tar ("tar"
not "GNU tar" :-), BSD ps ... In case of dd we have only options; in
case of tar ot ps, the first word consists of single letter options with
possible arguments in next words in order. There is no way to describe
both case with _arguments (unless I'm mistaken).

And I'd like repeat once more - currently, when _arguments is using
lexical structure to describe semantic, it is hard to add something. If
we had flags ... (not suggesting breaking compatibility - but just for
future use).

-andrej