Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support more values passed to --color(s) #2410

Closed
nordlow opened this issue Aug 19, 2022 · 2 comments
Closed

Support more values passed to --color(s) #2410

nordlow opened this issue Aug 19, 2022 · 2 comments

Comments

@nordlow
Copy link
Contributor

nordlow commented Aug 19, 2022

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?

@nordlow nordlow changed the title Support more values passed to --color Support more values passed to --color(s) Aug 19, 2022
@Geod24
Copy link
Member

Geod24 commented Aug 22, 2022

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.

@WebFreak001
Copy link
Member

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 to always if omitted)
  • diff --color=, diff --colour= (also supports leaving out =value, defaults to auto if omitted)
  • grep --color= (also supports leaving out =value, not specified what that means though)
  • ld.lld --color-diagnostics= (also supports leaving out =value, defaults to auto if omitted)
  • other tools unrelated to development I found working this way:
    • cal (--color defaults auto)
    • ip (-color defaults 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) and msbuild -clp:ForceConsoleColor (means always)

Boolean values:

  • ldc2 --enable-color=0 or 1 (means always, also supports leaving out =value, but that's undocumented usage - means 1 then)
  • dmd -color=on (always) or off (never) or auto (also supports leaving out =value, means on if 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.

WebFreak001 added a commit to WebFreak001/dub that referenced this issue Dec 15, 2022
Also improves error message output for unsupported --color values.
@Geod24 Geod24 closed this as completed in e3a6d29 Jan 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants