Re: Next release (5.3)

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Tue, 12 Jul 2016 22:23:08 +0200
Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> Bart wrote:
> 
> Thanks for the concise summary.
> 
> > The present situation is:
> >
> >     1. :a performs a string-manipulation on the path to remove any
> >        relative path segments.
> >     2. :A does (1) and then calls realpath on the result.
> 
> The only advantage I can think of that is that it might do what you want
> in the case where you don't have read permissions on one of the
> intermediate directories. Otherwise, the potential for the result being
> a different file is not good.

I've seen that last statement a lot recently and I think it's misleading.
It's not wrong but it's far from the whole story given the complexities
involved.

It's long-standing behaviour of zsh that by default directories are
managed logically, not physically, and hence that a ".." takes you up in
the logical hierarchy, i.e. the one you see in the string.

It's true that this case here isn't to do with $PWD or changing
directory etc. etc., but you don't know where the path you're applying
to the expression that's getting the :A has come from.  It might very
well have been something that was previously used for directory
management (it's a directory, after all).  In *that* case, changing the
behaviour of :A introduces bugs.  (Rather than it being a different
file, which is possible but unlikely, it's much more likely to refer to
something that doesn't exist at all --- less dangerous, but still
unhelpful.)

No one can actually point to a specific error case being fixed by the
change.

I suggest we focus on improving the documentation of :A, as the current
".." behaviour is one thing it *is* clear about so it's a little
bizarre to change *that*, to point out problems, and decide if we
actually want a new qualifier, which I think would be fairly
uncontroversial even if it's not frequently used.

pws