Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Bug in zparseopts -G?




On 9/4/2025 10:25 AM, Vin Shelton wrote:
While that is 100% correct; from a user's perspective the non-expansion of ~ is a bug.

From my POV, MAGIC_EQUAL_SUBST is at best a workaround.

Feel free to ignore this rant if it sounds like an old man shaking his fist at the sky:

Yes, arguing about defaults is for weenies, but from a usability perspective (I can speak from experience by getting old - I can't remember/learn what I used to), defaults matter (IMO, much more than continuity with the past). Our defaults (and documentation) are mostly complete and mostly accurate, but as a project, we're stuck in a pre-internet era. If I, as a user, have a comment (or complaint), I'm told the answer lies in a 1.5M character manpage! That's probably true, but quite unhelpful.

  - Vin
Well, I certainly agree with your "rant".


On Thu, Sep 4, 2025 at 10:47 AM dana <dana@xxxxxxx> wrote:
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



--
Whoa, I'm just surprised at how accurate that description of me really is:
some old cowboy guy that used to shoot movies at Spahn Ranch


Messages sorted by: Reverse Date, Date, Thread, Author