>> [...magic symlinks...]

[chuq@chuq.com]
> see the discussion of PR 30664 for why this is better as a
> system-wide knob.

Eh.  No.  For one argument for making it system-wide.  One I think is
actually a bad one.

Any fundamental change in the semantics of symlinks - and magiclinks
qualifies - means that all applications that use links need to be at
least looked at, and possibly updated.

Anything that uses readlink() and is broken by magic links simply needs
to be fixed to understand them, or the breakage tolerated, same as for
any other semantic change to symlinks.

Moving the @var processing to all pathname interpretation strikes me as
a very wrong change, especially as it suddenly means that @ is magic in
*all pathnames*.  Instead of two special pathname octets - 0x00 and '/'
- we now have three, a fairly drastic and fundamental change.  It's no
longer magiclinks at all, but magic pathnames in general.  That nobody
has suggested any use for magic pathnames except in symlink link-to
strings says strongly to me that there should be no such magic except
in symlink link-to strings.

realpath() already breaks in the case of execute-only symlinks on
filesystems mounted with MNT_SYMPERM.  Other conditions break
realpath() too, such as execute-only directories in the directory
chain.  Does this mean we have to remove all of those?  No more does
this realpath() breakage with magiclinks mean we have to do magiclinks
differently.

Yes, if abused they can be confusing.  But, as I remarked in the PR
thread, I defy anyone to name any useful facility of which that's not
true.

[nblists@anastigmatix.net]
> In that case, the sticky-bit suggestion ought to satisfy your desire
> for a way to mark them.

Yes, it would.

> I tend to agree with der Mouse that there needs to be some property
> of a path component that you must deliberately set if you want the
> component interpreted that way.  The sticky bit looks like it could
> work for the case where the component is a symlink.  What would be
> the corresponding marker for the general case?

As I said above, I don't think there should be any; I think the
realpath() issue is a red herring, and I think @ should not be special
except in symlink link-to strings, with the suggested marker being the
sticky bit on the symlink.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B