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