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