From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15315 invoked from network); 6 May 2000 07:52:30 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 May 2000 07:52:30 -0000 Received: (qmail 20189 invoked by alias); 6 May 2000 07:52:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11222 Received: (qmail 20173 invoked from network); 6 May 2000 07:52:23 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: "Tanaka Akira" , Subject: RE: PATCH: Re: sudo completion problem Date: Sat, 6 May 2000 11:51:56 +0400 Message-ID: <000901bfb72f$f33d73e0$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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 > > > - can somebody comment on long options case - is it > expected behaviour? > > Note, that I mean in this case "GNU long options". In this > case, again, > > _arguments should differentiate bewteen long and short > case, again with > > option. There are enough commands out there that use "long" > options but > > not GNU ones. > > It's not differences between long and short. It's caused by the > difference between traditional getopt and GNU getopt. > Yes, that is what I meant. > By default, GNU getopt permutes argv and finds options on anywhere > (until `--'). > > If we can easily find out whether a command is linked with GNU getopt > or not, we can (and should) complete correctly. > Well, hence I wrote "option for _arguments" for those commands, that use GNU getopt. > But I think the current behavior is not bad because it completes all > correct (and some non-correct) candidates. If _arguments behavior is > changed as you said, it completes only subset of correct candidates. > No, it does not complete "corect" canditates. It completes totally wrong set - options instead of arguments (files in case of diff). And this change was introduced a couple of weeks ago ... and nobody has ever complained before. I think, old behaviour is "the least evil" case because it applies in most cases. Apart from GNU getopt, there are commands that may intemix options and arguments (with semantic - "this option applies to following arguments" - do not have example ready) - but these are really special cases and should be treated as such. -andrej