From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17354 invoked from network); 2 Sep 2005 16:31:32 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 2 Sep 2005 16:31:32 -0000 Received: (qmail 23243 invoked from network); 2 Sep 2005 16:31:26 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 2 Sep 2005 16:31:26 -0000 Received: (qmail 19045 invoked by alias); 2 Sep 2005 16:31:17 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9368 Received: (qmail 19035 invoked from network); 2 Sep 2005 16:31:15 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 2 Sep 2005 16:31:15 -0000 Received: (qmail 22103 invoked from network); 2 Sep 2005 16:31:15 -0000 Received: from ns9.hostinglmi.net (213.194.149.146) by a.mx.sunsite.dk with SMTP; 2 Sep 2005 16:31:07 -0000 Received: from 212.red-80-35-44.pooles.rima-tde.net ([80.35.44.212]:32829 helo=localhost) by ns9.hostinglmi.net with esmtpa (Exim 4.52) id 1EBERa-0003Ql-B7; Fri, 02 Sep 2005 18:31:10 +0200 Date: Fri, 2 Sep 2005 18:35:15 +0200 From: DervishD To: Bart Schaefer Cc: Zsh Users Subject: Re: How to handle unknown options in zparseopts Message-ID: <20050902163515.GA962@DervishD> Mail-Followup-To: Bart Schaefer , Zsh Users References: <20050831154454.GA122@DervishD> <1050902161402.ZM22534@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1050902161402.ZM22534@candle.brasslantern.com> User-Agent: Mutt/1.4.2.1i Organization: DervishD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns9.hostinglmi.net X-AntiAbuse: Original Domain - sunsite.dk X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - dervishd.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Hi Bart :) * Bart Schaefer dixit: > On Aug 31, 5:44pm, DervishD wrote: > > tmp=$argv[1] > > > > [[ "$tmp[1]" == "-" ]] && { > > print "ERROR, unknown option \"$tmp\"" > > return 1 > > } > > That's pretty ugly and not very clean, neither :( > Why are you messing around with the tmp variable? Because I *keep* forgetting that zsh can compare with patterns. Sorry :((( > > But, worse, zparseopts spits an error in this case: > > > > set -- -a > > zparseopts -a array -- a: > > zparseopts -- a::=array > (( $#array == 1 )) && { > print -u2 "ERROR, required argument of \"-a\" is missing" > return 1 > } > > When you use 'a:' you tell zparseopts that *it* should require an > argument; but what you tell zparseopts doesn't have to literally > reflect whether *you* require one. Nice trick, thanks :))))) It doesn't work for my particular case, but it's a good base to think about a solution :) > However, that does mean that the argument must be given in the same > word as the option (e.g. "-axyz" rather than "-a xyz") so that may > not fit your needs. It doesn't, unfortunately :( But, why doesn't this work: set -- -a xyz zparseopts -A array -- a:: This doesn't consider 'xyz' as an argument to '-a'. OK, I've told to zparseopts that the argument is optional but this doesn't seem to be different from "zparseopts -A array -- a", without any colon :? Does that mean that optional arguments must ALWAYS go in the same word as the option? > There are two drawbacks to zparseopts; that's one of them, and the > other is that it doesn't differentiate empty strings from omitted > arguments very effectively. This drawback is not important for me. Really for my script there shoudn't be any difference between an empty string and a missing argument. > You might want to try a hybrid approach: Call zparseopts -D -E to > strip all the long options, then use getopts to process the rest of > them and issue error messages. However, that means that the order > of the options on the command line must not matter. That was my other idea ;) The order of the options does matter *only* if an option is repeated: the last value is the one that has to be used. Other than that, order is not important. I'll use the hybrid approach, I find it simpler and I can take advantage of already written code (I have already written the code for parsing short options) Thanks a lot for your help, Bart :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to...