How to handle unknown options in zparseopts

How to handle unknown options in zparseopts

[DervishD]

    Hi all :)

    After the suggestion of Doug for using zparseopts, I'm facing a
different problem. I don't want my script silently ignore unknown
options, I want to consider that an error. I don't know how to do it
since zparseopts doesn't report errors, so I've written this:

#!/bin/zsh

emulate -L zsh

typeset -A OPTIONS

zparseopts -D -A OPTIONS -- -help+

tmp=$argv[1]

[[ "$tmp[1]" == "-" ]] && {
    print "ERROR, unknown option \"$tmp\""
    return 1
}

# Handle here the other (valid) options

return 0


    That's pretty ugly and not very clean, neither :(

    But, worse, zparseopts spits an error in this case:

    set -- -a
    zparseopts -a array -- a:

    OK, it returns '1' but I'm pretty sure that it returns that value
for other errors, so I cannot 'silent' zparseopts by redirecting to
/dev/null and doing my own handling.

    Am I missing anything obvious? If I must handle myself unknown
options and the missing argument problem, I think I better use
getopts and handle long options myself :? GNU getopt is just another
pain in the arse, so...

    Thanks in advance :)

    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...

Re: How to handle unknown options in zparseopts

[Bart Schaefer]

On Aug 31,  5:44pm, DervishD wrote:
>
> zparseopts -D -A OPTIONS -- -help+
> 
> 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?

    zparseopts -D -A OPTIONS -- -help+
    [[ $1 = -* ]] && {
	print -u2 "ERROR, unknown option \"$1\""
	return 1
    }

>     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.

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.  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.

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.

Re: How to handle unknown options in zparseopts

[DervishD]

    Hi Bart :)

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

Re: How to handle unknown options in zparseopts

[Bart Schaefer]

On Sep 2,  6:35pm, DervishD wrote:
}
} >     zparseopts -- a::=array
} >     (( $#array == 1 )) && {

Actually I botched that.  $#array will always be 1, because the argument
(when present) is placed in the same array element as the option.  The
test should be [[ $array == -a ]].

}     set -- -a xyz
}     zparseopts -A array -- a::
} 
} Does that mean that optional arguments must ALWAYS go in the same
} word as the option?

Yes, that's what I was trying to explain.

Re: How to handle unknown options in zparseopts

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> }     set -- -a xyz
> }     zparseopts -A array -- a::
> } 
> } Does that mean that optional arguments must ALWAYS go in the same
> } word as the option?
> Yes, that's what I was trying to explain.

    Then I have a problem even using the hybrid solution, because all
long options I plan to add to the script have arguments (non optional
ones, by the way), so zparseopts it's going to whine a lot ;)

    Since most of the options are going to be short ones, I'll try to
parse long options manually or use GNU getopt (which I don't like
much, but...). Thanks 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...