Subject: Re: [PATCH v2 2/3] Fix the ':A' word modifier on paths with '..' components.
From: Daniel Shahaf <[email-masked]>
To: [email-masked]
Date: Fri, 01 Jul 2016 05:11:06 +0000
List-Id: Zsh Workers List <zsh-workers.zsh.org>

Bart Schaefer wrote on Tue, Jun 28, 2016 at 07:48:51 -0700:
> Therefore I think the only reasonable solutions are:
> (1) keep the current default and respect CHASE_DOTS to get the function
> Daniel wants, or
> (2) change the default and use :a:A to get the old behavior.
> 
> I lean slightly towards (1) but only because the doc has explicitly
> called out the "resolve .. first" behavior for the past 7 years.

What's the use-case for the "resolve '..' before symlinks" behaviour?

There doesn't seem to be a C stdlib function for it.

That behaviour (and the :A modifier) was added in 26731, but that thread
doesn't answer this question.

Was it an intentional design feature, or simply a documented bug?
(Honest question.)

> I floated the idea of testing CHASE_DOTS so that there would be a way
> to globally revert to the old behavior without having to update a lot
> of scripts, but I hadn't considered the "backward" semantics, and I'm
> not in favor of introducing a new option specifically for :A control.

(Perhaps instead of a new option, a new syntax; e.g., have $foo:A retain
its meaning and $foo:A:A have the new meaning.  Or make :A take an
optional argument.)

I get that a multitude of options is undesirable, and that making the
new behaviour conditional on an unset-by-default option helps
compatibility, but I'm wary of making a single option have two distinct
effects.

Each knob should do one thing and do it well.  Making chasedots affect
both 'cd' and :A will cause one of two things: either scripts that
'emulate -L zsh && setopt chasedots' for the setopt's effect on 'cd'
will get the new :A behaviour without explicitly opting in to it [which
seems to be your goal here], or people who wish :A to behave like
realpath(3) will have to use the chasedots version of 'cd'.

> However, with the current implementation there is NO way to obtain the
> semantics Daniel wants.

Thanks,

Daniel