From owner-svn-src-head@FreeBSD.ORG Fri Jun 19 21:54:28 2015 Return-Path: Delivered-To: svn-src-head@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D058B89E; Fri, 19 Jun 2015 21:54:28 +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 9575EA15; Fri, 19 Jun 2015 21:54:28 +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 36A49358C57; Fri, 19 Jun 2015 23:54:24 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 00D0428494; Fri, 19 Jun 2015 23:54:23 +0200 (CEST) Date: Fri, 19 Jun 2015 23:54:23 +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: <20150619215423.GA34741@stack.nl> References: <201506081913.t58JD5KX090442@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506081913.t58JD5KX090442@svn.freebsd.org> 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: Fri, 19 Jun 2015 21:54:28 -0000 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 > Modified: head/bin/ls/ls.c > ============================================================================== > --- head/bin/ls/ls.c Mon Jun 8 18:59:14 2015 (r284161) > +++ head/bin/ls/ls.c Mon Jun 8 19:13:04 2015 (r284162) > @@ -413,9 +413,14 @@ main(int argc, char *argv[]) > > /* > * If not -F, -P, -d or -l options, follow any symbolic links listed on > - * the command line. > + * the command line, unless in color mode in which case we need to > + * distinguish file type for a symbolic link itself and its target. > */ > - if (!f_nofollow && !f_longform && !f_listdir && (!f_type || f_slash)) > + if (!f_nofollow && !f_longform && !f_listdir && (!f_type || f_slash) > +#ifdef COLORLS > + && !f_color > +#endif > + ) > fts_options |= FTS_COMFOLLOW; > > /* 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). -- Jilles Tjoelker