zparseopts default associative array

zparseopts default associative array

[Sebastian Stark]

Hi,

if I have this script:

  typeset -A o
  o=(-a AAA -b BBB)
  zparseopts -K -A o a: b:
  print -- ${(kv)o[@]}

and run it such:

  ./script.sh -a foo

I would expect it to output "-a foo -b BBB". But the output is "-a
foo". In the manual the -K option to zparseopts is described as this:

"  -K     With this option, the arrays specified with the -a and -A
options and with the `=array' forms are kept unchanged when none of
the specs for them is used.  This  allows  assignment of default
values to them before calling zparseopts."

Maybe I misunderstood something, but isn't my example the intended use
of -K? Or is the condition "when none of the specs for them is used"
really meant like "if one option is given, all other default values
are emptied"? How would this make sense?

I tried with zsh versions 5.0.2 and 4.3.10.


Sebastian

Re: zparseopts default associative array

[Bart Schaefer]

On Feb 13,  8:17am, Sebastian Stark wrote:
}
} Maybe I misunderstood something, but isn't my example the intended use
} of -K? Or is the condition "when none of the specs for them is used"
} really meant like "if one option is given, all other default values
} are emptied"? How would this make sense?

Yes, it really does mean that the defaults are kept only if NONE of
the possible options for the array are parsed.  Although it applies to
the default arrays, the intended usage is really with the =array form
as in this snippet of Completion/Base/Core/_description:

    gropt=(-J)
    xopt=(-X)
    nopt=()
    zparseopts -K -D -a nopt 1 2 V=gropt J=gropt x=xopt

In this example -V and -J are mutually exclusive.  (There seem to be a
number of unnecessary uses of -K in the Completion tree.)  Before the
introduction of -K, gropt and xopt would have been unconditionally
erased by having merely been mentioned in the zparsopts arguments.

Yes, it would probably make sense for associative arrays if -K retained
individual elements for associative arrays, but the implementation does
the equivalent of the whole-array assignment o=(-a foo) for both plain
and associative arrays because there is no useful way to do individual
element assignment in the non-associative case.  Unfortunately -K was
an afterthought added with the minimal possible code changes.

Re: zparseopts default associative array

[Sebastian Stark]

Thanks for your very helpful answer. Is there any chance this gets
implemented one day or do I have to find a workaround? I am facing
changes to some scripts that used -K the wrong way, leading to funny
bugs.

2014-02-13 17:56 GMT+01:00 Bart Schaefer <schaefer@brasslantern.com>:
> On Feb 13,  8:17am, Sebastian Stark wrote:
> }
> } Maybe I misunderstood something, but isn't my example the intended use
> } of -K? Or is the condition "when none of the specs for them is used"
> } really meant like "if one option is given, all other default values
> } are emptied"? How would this make sense?
>
> Yes, it really does mean that the defaults are kept only if NONE of
> the possible options for the array are parsed.  Although it applies to
> the default arrays, the intended usage is really with the =array form
> as in this snippet of Completion/Base/Core/_description:
>
>     gropt=(-J)
>     xopt=(-X)
>     nopt=()
>     zparseopts -K -D -a nopt 1 2 V=gropt J=gropt x=xopt
>
> In this example -V and -J are mutually exclusive.  (There seem to be a
> number of unnecessary uses of -K in the Completion tree.)  Before the
> introduction of -K, gropt and xopt would have been unconditionally
> erased by having merely been mentioned in the zparsopts arguments.
>
> Yes, it would probably make sense for associative arrays if -K retained
> individual elements for associative arrays, but the implementation does
> the equivalent of the whole-array assignment o=(-a foo) for both plain
> and associative arrays because there is no useful way to do individual
> element assignment in the non-associative case.  Unfortunately -K was
> an afterthought added with the minimal possible code changes.

Re: zparseopts default associative array

[Bart Schaefer]

On Feb 14,  8:55am, Sebastian Stark wrote:
}
} Thanks for your very helpful answer. Is there any chance this gets
} implemented one day or do I have to find a workaround?

You should probably find a workaround anyway, because there will be
versions of zsh floating around for years that have the old behavior.