Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jul 2015 15:00:12 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Xin LI <delphij@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r284162 - head/bin/ls
Message-ID:  <20150719130012.GA23514@stack.nl>
In-Reply-To: <20150619215423.GA34741@stack.nl>
References:  <201506081913.t58JD5KX090442@svn.freebsd.org> <20150619215423.GA34741@stack.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150719130012.GA23514>