zsh[modules]/zutil: zparseopts should parse alternate long options

zsh[modules]/zutil: zparseopts should parse alternate long options

[toki clover]

Hi,

zsh/zutil is handy to get a nice parse option utilities and, in fact,
I use it often in scripts which permit to limit dozen of lines to just
parse options with getopt from GNU util-linux package. And once one
get used to it, one do not want to write again and again that long:
while [[ $# >0 ]]; do
case $1 in
   -o|--option) some_variable_asignement; shift;;
  ...
esac
done

case assignement.

Now, it would be nice if an alternate long option e.g. `-option'
instead of the GNU style `--option' would work, because in the present
day, if the first letter of a long option name is a short option name,
the long option would never be parsed as one would expect. So one
should use extra `-' hyphens to get his/her long option parsed, so to
speak, to use a la GNU style long option way.

Thanks.

Re: zsh[modules]/zutil: zparseopts should parse alternate long options

[Bart Schaefer]

On Apr 9,  2:12pm, toki clover wrote:
}
} Now, it would be nice if an alternate long option e.g. `-option'
} instead of the GNU style `--option' would work, because in the present
} day, if the first letter of a long option name is a short option name,
} the long option would never be parsed as one would expect.

An example would help to clarify your question.  Do any of the following
explain what you mean?  If not, could you provide a sample?

Given

    ARGV=(-option)
    zparseopts o=shortopts option=longopts

the entire string "-option" will be placed in the array "$longopts",
which seems to be what you want.  Given

    ARGV=(-option -o)
    zparseopts o=shortopts option=longopts

then $shortops will contain "-o" and $longopts will contain "-option".

In fact zparseopts normally attempts to make the longest match first, so
except in ambiguous cases option=longopts will always consume -option
before o=shortopts is attempted.  Only when no spec is matched that can
be treated as a single element does zparseopts fall back to handling
the prefix of -option as if it were -o.

The ambigous case happens with

    zparseopts option=longopts o:=shortopts

where -option could be parsed as either [-o with argument ption] or as
[-option].  The above would place (-o ption) in $shortopts and leave
nothing for $longopts.  However, this can be handled by making two
passes with separate specs:

    zparseopts -E -D option=longopts
    zparseopts -D o:=shortopts

In fact as currently implemented zparseopts scans the specs in reverse
order from last to first, so the above two passes are the same as

    zparseopts -D o:=shortopts option=longopts

but that's undocumented so not guaranteed to remain the case.  Since
using -E is an imperfect solution for the two-pass example, it would
probably not be unreasonable to suggest that the search order should
become documented and therefore trustworthy.