Re: Next release (5.3)

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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.

> This matches the documentation.
>
> Daniel is arguing that (1) is essentially useless and calling realpath
> after that may give a different result than realpath on the original
> path string.  His suggestion is:
>
>     1. :a is as before
>     2. :A calls realpath, and does (1) only if there is no realpath

That seems like a good approach. It might also try (1) if realpath fails.

I don't have many uses in scripts to check but I'd expect it'd be
more likely to fix scripts than introduce a bug.

With that approach, I guess you could get the original :A behaviour by
chaining the modifiers - :a:A

And adding modifiers just makes it harder to work out which one you
want. I could see a use for a pure readlink one, however.

> (It's unclear to me whether there would be any reason to do (1) AFTER
> calling realpath.)
>
> The emerging consensus seems to be for:
>
>     1. :a is as before
>     2. :A is as before
>     3. new modifier calls realpath and does (1) if no realpath
>
> Is there one of those three cases with which you agree, or are you in
> fact asking for zsh to re-implement realpath internally?

If systems lacking realpath were common, it would be worth doing
but from a check of online man pages it seems to be there on currently
relevant systems. Our own implementation might handle unreadable
directories followed by ../ but there might be some OS specific
oddities: case-insensitivity on macOS and Solaris xattrs come to
mind.

Oliver