Date: Sat, 8 Aug 2015 15:23:05 +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: <20150808132304.GA97913@stack.nl> In-Reply-To: <20150719130012.GA23514@stack.nl> References: <201506081913.t58JD5KX090442@svn.freebsd.org> <20150619215423.GA34741@stack.nl> <20150719130012.GA23514@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150808132304.GA97913>