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

Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net
Thu Aug 16 01:02:02 UTC 2018


> On Wed, Aug 15, 2018 at 2:55 PM, Rodney W. Grimes
> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> >> On Wed, Aug 15, 2018 at 2:34 PM, Rodney W. Grimes
> >> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> >> > [ Charset UTF-8 unsupported, converting... ]
> >> >> On Wed, Aug 15, 2018 at 12:43 PM, Rodney W. Grimes
> >> >> <freebsd at pdx.rh.cn85.dnsmgr.net> 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? =(

>From some other private discussion with Warner I think it may
be wise at this time to revert the MFC until some other things
are done in 12.0 to address some of the concerns and merge a
more complete solution.

Thanks,
Rod

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the svn-src-all mailing list