On Thu, Sep 4, 2025, at 11:19 AM, Clinton Bunch wrote:
On 9/4/2025 9:46 AM, dana 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:
I get it's how tilde expansion works, once I saw it I knew what was
happening, but it remains (at least IMHO) unexpected behavior when -G is
supposed to make command line parsing behave like other programs with
long options.
No doubt some programs do their own additional tilde expansion, but
many others don't. This is hardly some sort of universal convention.
% echo foo >~/pats
% printf '%s\n' foo bar baz fool >/tmp/in
% ggrep --file=~/pats /tmp/in
ggrep: ~/pats: No such file or directory
How many script users are going to expect that, though? And know that
what they need is magic_equal_subst? Would setting the option just
before zparseopts in the script fix it? (I'm not currently at a zsh
prompt to try). If not, perhaps -G should act as though
magic_equal_subst were in force while processing options.
I contend end users are going to expect any script using --option=~/path
to expand the tilde regardless if they have magic_equal_subst set in
their shell or not.
This is unfalsifiable projection.
So either the script writer is going to need to
know to set a shell option (I worked on this for over an hour last night
and never thought to check the manual for shell options, I was looking
at parameter expansion and later filename generation.) or zparseopts
needs to do it "out of the box".
No, zparseopts should not behave this way out of the box. Allowing
the script author to opt into an additional round of tilde expansion
might be okay.