From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1004 invoked from network); 4 May 2000 07:23:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 May 2000 07:23:47 -0000 Received: (qmail 15531 invoked by alias); 4 May 2000 07:23:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11139 Received: (qmail 15523 invoked from network); 4 May 2000 07:23:40 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: "Zefram" Cc: "Sven Wischnowsky" , Subject: RE: PATCH: Re: sudo completion problem Date: Thu, 4 May 2000 11:23:36 +0400 Message-ID: <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal > 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