Re: Bug in zparseopts -G?

[dana <dana@xxxxxxx>]

On Thu 4 Sep 2025, at 08:20, Clinton Bunch wrote:
> There seems to be a discrepancy in how zparseopts -G handles ~ paths.
>
> --option ~/path and --option=~/path are not equivalent.  In the first 
> the tilde is expanded (probably as part of the shell's parsing before it 
> gets to zparseopts) in the second it isn't.

it's not an issue with zparseopts, it's just how tilde expansion works:

> **Each word is checked to see if it begins with an unquoted ‘~’.** If
> it does, then the word up to a ‘/’, or the end of the word if there is
> no ‘/’, is checked to see if it can be substituted in one of the ways
> described here. If so, then the ‘~’ and the checked portion are
> replaced with the appropriate substitute value.

the word --option=~/path does not begin with a ~

you can change this behaviour by enabling magic_equal_subst:

> All unquoted arguments of the form ‘anything=expression’ appearing
> after the command name have filename expansion (that is, where
> expression has a leading ‘~’ or ‘=’) performed on expression as if it
> were a parameter assignment. The argument is not otherwise treated
> specially; it is passed to the command as a single argument, and not
> used as an actual parameter assignment. For example, in echo
> foo=~/bar:~/rod, both occurrences of ~ would be replaced. Note that
> this happens anyway with typeset and similar statements.

  % print -r - --option=~/path
  --option=~/path

  % setopt magic_equal_subst
  % print -r - --option=~/path
  --option=/Users/dana/path

dana