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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.