From owner-svn-src-all@freebsd.org Wed Aug 15 20:18:23 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 879AF106EF8F; Wed, 15 Aug 2018 20:18:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A7BC790E4; Wed, 15 Aug 2018 20:18:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id B72AF1728A; Wed, 15 Aug 2018 20:18:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f43.google.com with SMTP id f18-v6so1770796lfc.2; Wed, 15 Aug 2018 13:18:22 -0700 (PDT) X-Gm-Message-State: AOUpUlFQxR1I2RqzAHqhv++l6sF595bDQDK+d9qSzYCzWeHTmBzransg t4iTZMY1tZKcQCiP5DRjTB3rzpQuYKBGkMwSbSc= X-Google-Smtp-Source: AA+uWPxDjd1q+eTbNlCJdpeIZ8b9K6JW8zsExnEsMHKg9hJGSo5OMszJsgVH9V2q9vUmZFyJ0K4pyhHshfuDaBmvqbA= X-Received: by 2002:a19:be54:: with SMTP id o81-v6mr1917068lff.31.1534364301247; Wed, 15 Aug 2018 13:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 13:18:00 -0700 (PDT) In-Reply-To: <201808151955.w7FJt2Bk049460@pdx.rh.CN85.dnsmgr.net> References: <201808151955.w7FJt2Bk049460@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Wed, 15 Aug 2018 15:18:00 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r337826 - stable/11/bin/ls To: "Rodney W. Grimes" Cc: Adam Weinberger , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers , Ed Maste , svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:18:23 -0000 On Wed, Aug 15, 2018 at 2:55 PM, Rodney W. Grimes wrote: >> On Wed, Aug 15, 2018 at 2:34 PM, Rodney W. Grimes >> wrote: >> > [ Charset UTF-8 unsupported, converting... ] >> >> On Wed, Aug 15, 2018 at 12:43 PM, Rodney W. Grimes >> >> wrote: >> >> > >> >> > From the Linux man page at: http://man7.org/linux/man-pages/man1/ls.1.html >> >> > >> >> > Using color to distinguish file types is disabled both by default and >> >> > with --color=never. With --color=auto, ls emits color codes only >> >> > when standard output is connected to a terminal. The LS_COLORS >> >> > environment variable can change the settings. Use the dircolors >> >> > command to set it. >> >> > >> >> > Um, so by default we should not be doing any colour... and we are... >> >> > >> >> >> >> I don't recall making any argument that we're trying to match GNU >> >> ls(1) behavior. Furthermore, again, we aren't doing any color by >> >> default- only when the COLORTERM environment variable is set. >> > >> > So we are intentially being different? >> > >> >> No, we are not intentionally being different. See: the next paragraph, >> where I described that we've now-historically been honoring an >> environment variable for this and have simply added a more standard >> name for this variable. > > And one that is set by default many more places than the one that > had been set before, changing behavior people have been seeing for > a long time, and some of those people did not expect that, > nor seem to want it either. Will backing out the MFC and leaving this a 12.0 feature end this? =( Many changes we make fit the same same description that you just wrote, perhaps with "many many more places" replaced with "". Standardization is hard to argue against, leaving one knob to turn everything off or on and not having to have a profile full of: LSCOLORS=yes; export LSCOLORS GREPCOLORS=yes; export GREPCOLORS DPVCOLORS=yes; export DPVCOLORS ... I would hazard a guess that most people err to one side or the other: all the colors or none of the colors. >> >> >> >> >> ls(1) on FreeBSD historically honors -an- environment variable for >> >> enabling color. >> > >> > Short history, long history it had no color support at all. >> >> Color support in ls(1) is now old enough to drink having been >> introduced in 2000- I think that's long enough to call it >> "historically" here in 2018. > > ok, but for 25 years that ls has output in b&w even in > a colour terminal unless I took action to make it color output. And still, with a base FreeBSD install, you take action to make it color output. Some third party software claims COLORTERM for you, and you should be aware if this is the case. Not all color terminals will set COLORTERM for you. >> >> This environment variable is CLICOLOR. This commit >> >> switched the environment variable honored to the more-standard >> >> COLORTERM that is honored in other software and set by terminals that >> >> are generally expected to be used with color. >> >> >> >> I'm writing an UPDATING entry for this now to notify these users that >> >> they should remove COLORTERM from their environment if they do not, in >> >> fact, want a colored terminal. >> > >> > Is that the only way to turn this off? >> > That may not be desired either. >> > Atleast GNU ls allows me to force it off on command invocation >> > with --color=never, do we have an equivelent? >> > >> >> Sure- it gets turned off the same way it got turned on. =) > > Well, it now gets turned on when it was not turned on before, > and as is I now have to completly decolor to decolor ls(1), > I have no easy knob to turn off colorls only. > >> I'm >> certainly not averse to adding a --color long option, and will do so >> when I find the time (later today, most likely). > > That would help, atleast the annoyed can alias ls ls --color=never. > Ok > NB: from the GNU ls documentation there is a significant performance > impact with having colorls turned on as you now have to stat every > file in a directory listing. Is this also true of the BSD colorls? > No clue.