On Sat, Aug 18, 2018 at 12:35 AM, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> wrote: >> > On Fri, Aug 17, 2018 at 10:26 AM, Kyle Evans <kev...@freebsd.org> wrote: >> > > On Fri, Aug 17, 2018 at 10:24 AM, Rodney W. Grimes >> > > <free...@pdx.rh.cn85.dnsmgr.net> wrote: >> > >>> Author: kevans >> > >>> Date: Fri Aug 17 04:15:51 2018 >> > >>> New Revision: 337956 >> > >>> URL: https://svnweb.freebsd.org/changeset/base/337956 >> > >>> >> > >>> Log: >> > >>> ls(1): Add --color=when >> > >>> >> > >>> --color may be set to one of: 'auto', 'always', and 'never'. >> > >>> >> > >>> 'auto' is the default behavior- output colors only if -G or >> > >>> COLORTERM are >> > >> >> > >> Why different than coreutils ls? Default for coreutils is none. >> > > >> > > I guess this was worded poorly and you skipped both the review and >> > > reading the diff... this is still contingent on environment variables >> > > or -G being specified. >> > > >> > >>> set, and only if stdout is a tty. >> > >>> >> > >>> 'always' is a new behavior- output colors always. termcap(5) will be >> > >>> consulted unless TERM is unset or not a recognized terminal, in >> > >>> which case >> > >>> ls(1) will fall back to explicitly outputting ANSI escape sequences. >> > >>> >> > >>> 'never' to turn off any environment variable and -G usage. >> > >> Why different than core utils? Coreutils uses none. >> > > >> > > I guess this was worded poorly and you skipped both the review and >> > > reading the diff... this is still contingent on environment variables >> > > or -G being specified. >> > > >> > >> > ... copy-paste-o. The version of coreutils ls(1) that I have uses >> > 'never' for this. There is no valid 'none' value. >> >> Oh boy, we need to investiage that then, cause it seems >> as if the official page says none. Does your say it >> has a different default value too? > > And our package of gnu coreutils also says never, so ignore my > raising the issue of none vs never, that needs to be raised > with the gnu folks as it seems as if there online manual and > the code is in conflict. Ooopss.. retract that here we go... > I have our pkg coreutils installed:
This is what I was afraid of. =( > root@x230a:~ # gls --color=none > 828phone.tgz Desktop Downloads firefox.core soffice.bin.core > root@x230a:~ # gls --color=never > 828phone.tgz Desktop Downloads firefox.core soffice.bin.core > root@x230a:~ # gls --color=theychangedit > gls: invalid argument 'theychangedit' for '--color' > Valid arguments are: > - 'always', 'yes', 'force' > - 'never', 'no', 'none' > - 'auto', 'tty', 'if-tty' > Try 'gls --help' for more information. Except that's even worse than I thought... I assumed it was "always"; "never", "none"; "auto" having kept both "never" and "none" for backwards compat. =\ > So it looks as if we need to add a we bit > more to make our use of --color match what > coreutils actually allows. > > *Runs and ducks* cause Kyle has already gone way above > the call of duty on this one! More than happy to add all of these aliases so that we do the right thing if the user is explicit. =) I generally just don't want to change the default behavior away from respecting the environment/-G since we've done this for so long now. I believe in compatibility with GNU tools so that user doesn't get surprised when an option they want doesn't exist (see: the various long options commits I've made in the past), but I believe a lot less in bending how we do things by default to match when we already have our own precedent set. Thanks, Kyle Evans _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
