svn commit: r337826 - stable/11/bin/ls

[Kyle Evans]

On Thu, Aug 16, 2018 at 4:29 AM, Alexey Dokuchaev <danfe at freebsd.org> wrote:
> On Wed, Aug 15, 2018 at 02:32:54PM -0600, Warner Losh wrote:
>> On Wed, Aug 15, 2018 at 2:28 PM, Ian Lepore <ian at freebsd.org> wrote:
>> > On Wed, 2018-08-15 at 13:26 -0700, Rodney W. Grimes wrote:
>> > > >
>> > > > Will backing out the MFC and leaving this a 12.0 feature end this?
>> > > =(
>> > >
>> > > Sadly no, as the person responded with that reaction when
>> > > they installed 12.0-ALPHA :-(.
>> >
>> > So one whiner can demand of the project that any new feature be removed
>> > before a new release is made?
>>
>> This is a good change.
>
> It might be a good change, but it's also very controversial.  Traditionally,
> ls(1) was colorless by default.  I don't mind adding COLORTERM (albeit see
> no reason for this: those who wanted colors could always added -G option to
> their ls(1) alias or set CLICOLOR variable), but it should definitely lean
> to being colorless unless explicitly asked.  As Rod had pointed out, colors
> mean you now have to stat(2) file listed which is a significant performance
> impact.
>
> So yeah, there are reasons why people are so fussed about it.  Why fix
> something that ain't broken?  Why break POLA?
>

Please read the diff before responding with stuff like this and your
below e-mail. It was already long backed out by the time you
responded, and it behaves exactly as you mention in your first
paragraph -- COLORTERM must be set to get color, with the caveat that
people apparently don't realize their terminal modifies their
environment and sets COLORTERM in addition to setting TERM
appropriately.

Agreed on the documentation, though there's a lot of other things that
also invoke the stat(2).

Thanks,

Kyle Evans