Re: [bug] :P modifier and symlink loops

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Thu, 24 Apr 2025 20:17 +00:00:
> On Thu, Apr 24, 2025 at 11:36 AM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>> >
>> > Patch six in this series breaks whence -s, I guess it is not a very
>> > common usecase since nobody complained until now.
>> > Expected:
>> > % Src/zsh -c 'which -s git'
>> > /usr/bin/git
>> > Actual:
>> > % Src/zsh -c 'which -s git'
>> > /usr/bin/git -> /usr/bin/git
>> >

Oops.

Could someone add a quick 'f'-flagged test for this for me, please?
Something like the following ought to do it:

[[[
 whence -s =sh(:P) | grep '.->' | wc -l
-fD:whence -s doesn't print arrows for symlink-free paths
>0
]]]

(per usual, the '-' and 'D' are only to remain until the 'f' is removed)

>> > Reverting the patch seems to resolve the issue, but I'm not sure what
>> > the intent of the change was in the first place
>
> Eliminate excess work done by xsymlinks, I think.
>

Sorry it wasn't clear.

To clarify, I think the intent of patch 6 was to pave the way for the
simplification of xsymlinks() in patch 7:

Patch 4 removed one callsite of xsymlinks(full=1).  Then, patch 6
removed another such callsite.  These two between them made it possible
to remove that codepath altogether in patch 7.  Patch 5 was between
them, presumably to demonstrate that patch 6 didn't cause a behaviour
change for the cases tested by patch 5.

Furthermore, the log message of patch 8 implies that the removed
codepath wasn't entirely bug-free.  Perhaps patch 4 made the bug latent,
and then patch 7 fixed it properly (as in, made the bug impossible to be
triggered by any putative subsequent caller of xsymlinks()).

>> > I know that Daniel isn't very active anymore, but if anyone else has
>> > any thoughts?
>
> We could resolve the issue without adding back the xsymlnks call if we
> could tell that chrealpath has returned the exact same path it was
> given.

Cheers,

Daniel