From owner-svn-src-head@freebsd.org Sun Jul 19 13:00:16 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FF8B9A6D59; Sun, 19 Jul 2015 13:00:16 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4985314BD; Sun, 19 Jul 2015 13:00:16 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D8CAD358C62; Sun, 19 Jul 2015 15:00:12 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id BCDC428494; Sun, 19 Jul 2015 15:00:12 +0200 (CEST) Date: Sun, 19 Jul 2015 15:00:12 +0200 From: Jilles Tjoelker To: Xin LI 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> References: <201506081913.t58JD5KX090442@svn.freebsd.org> <20150619215423.GA34741@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150619215423.GA34741@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 13:00:16 -0000 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