K 10
svn:author
V 6
kevans
K 8
svn:date
V 27
2020-06-05T02:56:42.491073Z
K 7
svn:log
V 1266
MFC r361318, r361331-r361332

r361318:
ls: fix a --color regression from r337956

The regression is in-fact that I flipped the default from never to auto. The
incorrect impression was based on an alias that I failed to notice,
installed by the Linux distribution that I used for testing compatibility
here. Users that want the old default should be doing so with a shell alias
as is done elsewhere, rather than making this decision in ls(1).

Many thanks to rgrimes for pointing out the alias that I clearly overlooked
that resulted in this; if you despised colors in your terminal from this,
consider buying him a beer at the next venue that you see him at.

r361331:
ls(1): actually restore proper behavior

Highlights:
- CLICOLOR in the environment should imply --color=auto to maintain
  compatibility with historical behavior
- -G should set CLICOLOR and imply --color=auto

The manpage has been updated to draw the connection between -G and --color;
the former is in-fact a sort of compromise between --color=always and
--color=auto, where we'll output color regardless of the environment lacking
CLICOLOR/COLORTERM assuming stdout is a tty.

r361332:
ls: fix WITHOUT_LS_COLORS build

*sigh* references to colorflags should be gated by COLORLS.

Relnotes:	yes

END