ls colour (COLORTERM / CLICOLOR)
James Wright
james.wright at digital-chaos.com
Mon Jul 20 17:40:37 UTC 2020
On 20/07/2020 14:26, Kyle Evans wrote:
> On Sat, Jul 18, 2020 at 7:51 PM James Wright
> <james.wright at digital-chaos.com> wrote:
>>
>> Updated to 12.1-STABLE r363215 a few days ago (previous build was
>> circa 1st June)
>> but seem to have lost "ls" colour output with "COLORTERM=yes" set in my env.
>>
>> Setting "CLICOLOR=yes" seems to enable it again, however the man page
>> states that
>> setting either should work?
>>
> Hi,
>
> Indeed, sorry for the flip-flopping. The short version of the
> situation is that I had flipped ls(1) to --color=auto by default based
> on a misunderstanding of defaults elsewhere due to shell aliases that
> I hadn't realized were in use. The ls(1) binary is historically and
> almost universally configured for non-colored by default where color
> support exists, and you should instead use appropriate shell alias for
> ls=`ls -G` or `ls --color=auto`.
>
> I can see where the manpage could describe the differences a little
> better. CLICOLOR (On FreeBSD) historically meant that we'll enable
> color if the terminal supports it, and setting it would have the same
> effect as the above shell alias. COLORTERM is less aggressive and
> won't imply any specific --color option, you would still --color=auto
> to go with it for it to have any effect.
>
> Thanks,
>
> Kyle Evans
Thank you for the clarifying the diferences between CLICOLOR and COLORTERM,
that makes sense to me now. I'll set the shell alias and remove COLORTERM.
Only raised this in case it was an unintended consequence of recent
changes. :-)
More information about the freebsd-stable
mailing list