-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
CmdLineArgs: Determine whether to color output based on TERM
variable
#13486
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the same issue when watching the console output in Eclipse. So I don't think this a compile time issue. Can we detect it at runtime?
Is the CMake output correct colored? |
CMake logs aren't shown in Xcode (at least I haven't found where). I think it's somewhat of an IDE-specific issue, but since iOS apps are rarely run outside of Apple's tools (Xcode/Console.app), I don't think it makes sense to use ANSI colors if those terminals don't support them. |
How about the compiler output? is that colored? |
This a also an interesting article: |
IIRC Xcode hides the raw compiler output in a submenu, so I'd have to check whether that supports ANSI colors. The runtime console is different though. |
clang seems also be able to detect color capability:
|
I consider that to be a separate issue, this is about Mixxx' runtime logs. I agree that we might want to put more effort into detecting the terminal though. We might be able to detect if we run in Xcode via environment variables. On the other hand, I think defaulting to non-colored output on iOS is probably safer since apps have little control over how and where the OS aggregates those logs. |
QT has also a private function for it: |
Ah interesting, checking the |
ed7c889
to
9188bad
Compare
TERM
variable
I have updated the PR to determine whether a terminal supports colors based on the The PR also targets 2.5 now, since this is a rather minor fix that might be useful there too. |
The sporadic macOS CI failures (e.g. this one) are a known issue btw: actions/runner-images#7522 Re-running the workflow usually fixes it, but of course that isn't ideal. For my m1xxx build I use a workaround which kills the XProtect process that supposedly interferes with |
src/util/cmdlineargs.cpp
Outdated
return term == "ansi" || term == "cygwin" || term == "linux" || | ||
term.startsWith("screen") || term.startsWith("xterm") || | ||
term.startsWith("vt100") || term.startsWith("rxvt") || | ||
term.endsWith("color"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please also add alacritty
and xterm-256color
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xterm-256color
is already handled by the last condition. Is alacritty
the full string or is it suffixed with -...color
too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the full string:
$ echo $TERM
alacritty
$
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on second thought, let's invoke tput colors
to check for color support instead. If the command is not available, we just don't use colors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's probably a cleaner solution indeed. Only downside is that we'd have to spawn a process at every launch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should check for platforms where we can't spawn processes (Wasm/iOS) too, but otherwise that looks good I'd say. I'll have a look at integrating it later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I'm not sure if this would work on Windows (though the TERM
heuristic probably wouldn't either), @JoergAtGithub do you by chance know if there's tput
there or if there is another way of checking for colors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm unfamilar with this topic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Windows I think we need to call GetConsoleMode()
and check if the ENABLE_VIRTUAL_TERMINAL_PROCESSING
flag is set.
Also see https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be useful: build2/build2#312 (comment)
I am reluctant of using tput. tput is part of ncurses, and just a thin wrapper around a library call. The process call at the startup is kind of fragile and requires a good portion of error handling. Instead let's follow CMake and use PDCurses that is for my understanding a wrapper around ncurses but works also for other targets. https://github.com/wmcbrine/PDCurses |
https://pdcurses.org/docs/MANUAL.html#portability-8 |
Both pdcurses and ncurses require adding a dependency. IMO we could look into something in the future, but I'd love to move my iOS branch closer to upstream to avoid having to patch around these minor things. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with merging this in the current state. I'm also weary of adding new dependencies.
For simplicity, we could consider opting for something like this in the future: http://bixense.com/clicolors/ so that users have a way to force ANSI colors in case the autodetection is not working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am also fine with the current state. Thank you.
To avoid cluttering up the output with ANSI escape sequences in terminals that do not support them (e.g. Xcode), this adds a heuristic that checks the
TERM
environment variable.