Re: [bug] :P modifier and symlink loops

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Daniel Shahaf wrote on Sat, 21 Mar 2020 19:50 +0000:
> Patch series attached.
> 
> I ended up implementing the second option — keeping the trailing
> components verbatim — for several reasons:
> 
> 1. It's actually documented this way for :P.  (xsymlink() has other
> callers too, but I didn't check whether any of them specifically relied
> on this behaviour.)
> 
> 2. After I made the code use the realpath() wrapper function,
> chabspath(), rather than xsymlinks() (plural), that's the behaviour
> I observed, and I didn't go out of my way to change it.
> 
> I suppose we could revisit :P's behaviour on symlink loops with
> trailing components after the loop, but in the meantime, this at least
> fixes the segfault.
> 
> WDYT?

For the record, redirecting xsymlink() [singular] to use chrealpath()
rather than xsymlinks() [plural] has a side effect: it will make the
call fail immediately on systems that don't have realpath(3) available.
The following places are affected:

- setting $HOME
- 'ztie' in the gbdm module
- the :P modifier in history and parameter expansions
- the helper functions findpwd(), getnameddir(), check_autoload(),
  dircache_set()

I suppose that basically means realpath(3) is required.  It was added in
4.4BSD (1995) and has been in POSIX since 2004 if not earlier, so I'll
go ahead and push this series — but if it breaks anything, holler.

Cheers,

Daniel