Re: [PATCH 2/2] _arguments: Add the -0 flag, which makes $opt_args be populated sanely.

[Daniel Shahaf <d.s@daniel.shahaf.name>]

oxiedi@yandex.ru wrote on Tue, 28 Apr 2020 14:37 +0500:
> > With this, «local -a values=( ${(0)opt_args[--foo]} )» would get the
> > value or values of the --foo option, as typed on the command line.
> > Without this, the completion function would have to reverse the "escape
> > colons and backslashes and join with colons" operation, and I don't know
> > of an easy way to do that.  
> 
> I've used
> 
>     local -a values
>     IFS=: read -A values <<<$opt_args[--foo]
> 
> once. Does it have some drawbacks?

Good idea, thanks.

It would DTWT when there's a literal newline in ${opt_args[--foo]}.

Also, it requires an additional temporary variable before accessing
${opt_args[--foo]} whenever the value of --foo may contain colons, even
if the --foo option is not repeatable.

On the other hand, the NUL separators approach would DTWT when there is
a literal NUL in the arguments.  That could in theory happen when
completing the arguments to a builtin.  If someone runs into _that_,
they should implement and use dana's ${(s.:..\.)} [grep for «spsep»],
or invent another way for _arguments to communicate the values to its
caller.

Thanks again,

Daniel