Re: How to handle unknown options in zparseopts

[DervishD <zsh@xxxxxxxxxxxx>]

    Hi Bart :)

 * Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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...