Re: Next release (5.3)

[Filipe Silva <filipe.silva@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

Wait good people. Maybe I am missing something, but why the specific focus
on the non-posix `realpath`? Doesn't `readlink -f` emulates what realpath
does but it is always available because it is posix? Maybe :A should really
call `readlink -f`? Makes sense?

On Tue, Jul 12, 2016 at 5:23 PM, Oliver Kiddle <okiddle@yahoo.co.uk> 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.
>
> > 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
>