svn commit: r284162 - head/bin/ls

Jilles Tjoelker jilles at stack.nl
Sat Aug 8 13:23:10 UTC 2015


On Sun, Jul 19, 2015 at 03:00:12PM +0200, Jilles Tjoelker wrote:
> On Fri, Jun 19, 2015 at 11:54:23PM +0200, Jilles Tjoelker wrote:
> > On Mon, Jun 08, 2015 at 07:13:05PM +0000, Xin LI wrote:
> > > Author: delphij
> > > Date: Mon Jun  8 19:13:04 2015
> > > New Revision: 284162
> > > URL: https://svnweb.freebsd.org/changeset/base/284162

> > > Log:
> > >   It has been long time that when doing 'ls -G /path/to/a/symlink',
> > >   instead of using the color of symbolic link, the color is
> > >   determined by the link target. This behavior was quite confusing.

> > >   Looking at the file history, it looks like that r203665 intends to
> > >   fix this but the issue was never actually fixed.

> > >   Fix this by not setting FTS_COMFOLLOW when color is requested like
> > >   what was done in r203665.

> > >   MFC after:	2 weeks

> > > Modified:
> > >   head/bin/ls/ls.c

> > Hmm. This makes -G or CLICOLOR env behave like -F in that symlinks are
> > no longer followed by default. This at least needs a change in the man
> > page to document it, and I'm not sure whether -G should actually modify
> > ls's action beyond adding colour.

> > For example, in stable/10 doing ls /sys, ls -p /sys and ls -G /sys show
> > a directory listing of the kernel source, while ls -F /sys shows just
> > the symlink.

> > What r203665 fixed was colour, inode number, etc. when -P was given and
> > -F/-d/-l were not.

> > I'll admit that this -F/-d/-l thing is bizarre but it has grown that way
> > historically and I've found ls implementations that deviate from this
> > annoying (e.g. on some embedded systems).

> What's more, the behaviour even depends on TERM, leading to strange
> things like:

> $ TERM=dumb CLICOLOR=1 ls /sys
> Makefile        crypto          libkern         netsmb          sparc64
> amd64           ddb             mips            nfs             sys
> arm             dev             modules         nfsclient       teken
> arm64           fs              net             nfsserver       tools
> boot            gdb             net80211        nlm             ufs
> bsm             geom            netgraph        ofed            vm
> cam             gnu             netinet         opencrypto      x86
> cddl            i386            netinet6        pc98            xdr
> compat          isa             netipsec        powerpc         xen
> conf            kern            netnatm         rpc
> contrib         kgssapi         netpfil         security
> $ TERM=xterm CLICOLOR=1 ls /sys
> /sys
> $ 

> The bottommost /sys is purple.

OK, I thought some more and looked at how GNU ls deals with this issue.
My goal is to remain POSIX-compliant about following symlinks (ignoring
colour) while still colouring a command line symlink to a non-directory
as a symlink in the default mode.

What makes this complicated are the -i, -p, -s, -S and -t options, which
show stat information without disabling the implicit following of
symlinks like -F and -l do.

What GNU ls seems to do is not follow command line symlinks to
non-directories. As a result, ls -i symlink_to_non_directory shows the
symlink's inode number instead of the target's required by POSIX. This
bug applies both in colour and non-colour mode.

To avoid POSIX violations and keep the colour consistent with
information shown by -i/-p/-s/-S/-t, we could revert r284162 and skip
following command line symlinks to non-directories only if -i/-s/-S/-t
are not given (-p only affects display of directories, so it is
irrelevant here). This would involve adding an lstat() call to
printaname() if p->fts_level == FTS_ROOTLEVEL and a flag set in ls.c is
true. It would also require additions to the man page.

An alternative is to revert r284162 and do nothing else. This does not
require any man page changes but users may expect seeing symlink colour
when listing a symlink to a non-directory in the default mode.

What do you think?

-- 
Jilles Tjoelker


More information about the svn-src-head mailing list