Subject: Re: bug#25261: ls -L: also allow seeing intermediate links

From: Eric Blake <[email-masked]>
Date: Tue, 27 Dec 2016 15:21:19 -0600

tag 25261 notabug
thanks

On 12/24/2016 06:10 AM, 積丹尼 Dan Jacobson wrote:
> $ man ls
>        -L, --dereference
>               when showing file information for a symbolic link, show informa-
>               tion  for  the file the link references rather than for the link
>               itself
> 
> Ah ah ah... so one can only see the first (no -L) or last (-L) of a
> e.g., long chain of symbolic links.

Correct, because that's all the kernel gives you, via lstat() (no -L) or
stat() (-L).  Since the kernel has no atomic way to stop halfway through
a chain of symlink resolution (other than the fact that it stops with
ELOOP if the chain would resolve but not in the amount of finite
resources the kernel is willing to allot to the resolution), the best
you could do is non-atomic approximations by a series of readlink()
kernel calls, if you don't mind being subject to a TOCTTOU race condition.

> Perhaps add a --symbolic-link-depth
> option to be able to see where an arbitrary depth of symbolic links
> points to.

You can already use the readlink and/or realpath utilities to follow a
chain of symlinks one link at a time.  And ls is already bloated enough
that the bar is REALLY high for adding any new options, especially if
the option is not already existing practice in some other
implementation, or if the action could be performed via other existing
command line tools.

> Or add a -L1, -L6, -L14 ... option.

Not possible.  There is no way using getopt_long() to differentiate
plain '-L' to mean something different than '-L1' - it gets parsed the
same as '-L -1'.  And we are not going to turn -L from no argument into
an optional argument, as that would break existing users.

Because what you seem to want is already available through readlink, I'm
closing this as not a bug.  But feel free to add further arguments, or
propose a patch rather than just idle musings if you think there is more
that we're overlooking.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org