dub
dub copied to clipboard
Support more values passed to --color(s)
Rust's default build tool, cargo allows the following values passed to --color
--color <WHEN> Coloring: auto, always, never
. I find those namings a bit more natural. Shall we support those as aliases aswell?
No. on and off are simple to remember and to type, and IMO it's better to have one way to do it than a flurry of names.
comparing with other linux tools: (checked random dev utilities and https://wiki.archlinux.org/title/Color_output_in_console)
Users of auto, always, never:
gdc -fdiagnostics-color=ls --color=(also supports leaving out =value, defaults toalwaysif omitted)diff --color=,diff --colour=(also supports leaving out =value, defaults toautoif omitted)grep --color=(also supports leaving out =value, not specified what that means though)ld.lld --color-diagnostics=(also supports leaving out =value, defaults toautoif omitted)- other tools unrelated to development I found working this way:
cal(--colordefaults auto)ip(-colordefaults always)dmesg(--color` defaults auto)
Simple flags:
less --use-color(unsure what it means, as this tool only works with a tty, it pretty much maps to "auto", because otherwise it just outputs the file as-is)npm --no-color(means never)pip --no-color(means never)tsc --pretty(means always in my test, but actual meaning / behavior is undocumented)msbuild -clp:DisableConsoleColor(means never) andmsbuild -clp:ForceConsoleColor(means always)
Boolean values:
ldc2 --enable-color=0or1(means always, also supports leaving out =value, but that's undocumented usage - means1then)dmd -color=on(always) oroff(never) orauto(also supports leaving out =value, meansonif omitted)
Other:
- git uses
color.ui,color.<subcomponent>config with true (= always) / false / auto - npm also has
npm config set color <value>with true (= auto) / false / always
Just with development tools they look pretty even, but most GNU and linux utilities seem to use the auto, always, never scheme.
Additionally looking at the other tools, it seems sometimes unclear what even simple booleans mean (does on mean always or auto?) and in any way it's unclear if omitting values means auto or always. The unclear behavior with the tools that use these values makes it even more unclear for tools using booleans.
So I think it makes sense if we switch to that as well (can keep on and off supported for backwards compatibility) because it looks like auto, always and never is actually more widely used, thus probably easier to remember by most developers.