svn commit: r284162 - head/bin/ls
Jilles Tjoelker
jilles at stack.nl
Sun Jul 19 13:00:16 UTC 2015
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
More information about the svn-src-head
mailing list