Console colors not working on macOS 10.14.5 about corrade HOT 17 CLOSED

I guess it would pass if you invert the condition here?

I tried it and it passes without any errors, your right once again.

I can't check for the environment variables myself because I don't have Xcode installed. I got those variables from this gist, but it's from 2014 or something like that and I don't know how reliable it is or if those variables do even exist nowadays...

I'm trying to find an up-to-date list of environment variables defined by Xcode so we can fix this quick.

from corrade.

Both the Xcode terminal window (left) and a bash shell (on the right), both working as intended:

Looks good to me! :)

from corrade.

Thank you! Pushed to master.

from corrade.

Okay, I just read the documentation and I realize passing the parameter --color on to the application enables colors, but they are disabled by default (aka if nothing is passed or if --color auto is given to the application as a parameter). This behavior differs from for example Linux, where it is enabled if nothing or if --color auto is passed to it.

I'm sorry, I should have read the documentation before opening this issue. Reading the documentation I suspect the library is not detecting bash on macOS as an interactive TTY which might be an issue anyway. Is this behavior to be expected or is it some sort of minor bug?

from corrade.

Hi, thank you for the report!

I'm sorry, I should have read the documentation before opening this issue

No worries. Yes, it seems that it's somehow related to TTY detection, but that one was definitely working last time I tried :) Unfortunately I don't have direct access to macOS right now, can you build Corrade with tests enabled (the BUILD_TESTS option in CMake) and then run build/src/Corrade/Utility/Test/UtilityDebugTest (or roughly around that location depending on your buildsystem)? There it has a bunch of tests for Debug::isTty(), which does the TTY detection. Can you paste the relevant part of the test output here?

In that function, there's a macOS-specific workaround that aims to disable colors when running inside Xcode. There's no reliable way to detect that, so it checks for the XPC_SERVICE_NAME environment variable, which, according to my tests ~three years ago, was always set inside Xcode and never outside. Is there a possibility you have this var set in your Bash environment as well?

from corrade.

Even though I'm not using Xcode, somehow the variable XPC_SERVICE_NAME was set to 0. You're right! :)

After undefining it and running the example again, the colors are enabled by default. Also, I ran all the tests using ctest and all of them except UtilityDirectoryTest passed successfully, including UtilityDebugTest.

My guess is that some Xcode service running in the background sets this variable even if using bash directly (i.e. not compiling anything under Xcode). A possible solution might be to add an option to CMake to force enabling colors, or maybe just check the environment variable if we're building for Xcode. Or maybe just undefining that variable every time is okay too :)

I have some free time. I can test, debug and open a PR with a fix for this if you want. Oh, and thanks for the library! It's really nice, well documented and useful!

from corrade.

Thank you!

all of them except UtilityDirectoryTest passed

I'd be interested in what failed there. The CI says it's all good, but that's just a statistical sample size of 1 :)

A possible solution might be to add an option to CMake to force enabling colors

This should stay a runtime option. If you could figure out any other environment variable (or a combination of them) that would make this check more robust, that'd be great. Maybe there's some env var that's always set when running from Bash but never set when running from Xcode that could be used in addition to checking for XPC_SERVICE_NAME? Or maybe I just failed to google properly and there is a reliable way to detect if the exe is running inside Xcode?

from corrade.

This is the full output of UtilityDebugTest (with XPC_SERVICE_NAME disabled) in case you need it:

Debug output is a TTY?   yes
Warning output is a TTY? yes
Error output is a TTY?   yes
...
Finished Corrade::Utility::Test::DebugTest with 0 errors out of 106 checks.

And this is the output with the variable defined to its default value:

Starting Corrade::Utility::Test::DebugTest with 54 test cases...
Debug output is a TTY?   no
Warning output is a TTY? no
Error output is a TTY?   no
...
Finished Corrade::Utility::Test::DebugTest with 0 errors out of 106 checks.

All the tests in the middle passed successfully.

from corrade.

Or maybe I just failed to google properly and there is a reliable way to detect if the exe is running inside Xcode?

Hmm, googling for XPC_SERVICE_NAME, it looks like many people have it defined in the shell, so it's not a reliable check at all :/ And checking if it's 0 or some other value doesn't seem like a good idea either.

from corrade.

I'd be interested in what failed there. The CI says it's all good, but that's just a statistical sample size of 1 :)

This is what fails on that test:

If you could figure out any other environment variable (or a combination of them) that would make this check more robust, that'd be great.

Maybe we could check against some other Xcode-specific variable, like XCODE_PRODUCT_BUILD_VERSION, XCODE_VERSION_ACTUAL, XCODE_VERSION_MAJOR, XCODE_VERSION_MINOR

from corrade.

What filesystem are you on? The test assumes it's HFS+ and there Apple does Unicode decomposition so e.g. ě is stored separately as e and a combining ˇ and so it's not bit-exact as what's in the source (but OTOH there's absolutely no difference in rendering, so it looks suspicious, hehe) -- I guess it would pass if you invert the condition here?

XCODE_PRODUCT_BUILD_VERSION, XCODE_VERSION_ACTUAL, XCODE_VERSION_MAJOR, XCODE_VERSION_MINOR

IIRC I didn't see any of those variables in the environment listing when running inside Xcode (otherwise I would use them, as they are vastly more self-explanatory than the XPC_SERVICE_NAME) :) But it was a long time ago, things could change since then. If you want to quickly try, Utility::Debug{} << Utility::Arguments::environment(); prints all the env vars.

from corrade.

Is there any other option which doesn't involve checking for environment variables? I can't find any updated list with the variables defined by Xcode.

Maybe we could check which generator is using CMake. If we're building an Xcode project, then set a macro which disables colors by default (but could be forced with --color on). If not, just leave it enabled by default just like it is on Linux and other systems. This is a bit more work but seems more reliable to me than checking for an environment variable that we can't know for sure or may change in the near future :)

from corrade.

I can't find any updated list with the variables defined by Xcode.

That list above doesn't have XPC_SERVICE_NAME at all and is much longer than I remember, I'm not sure if it's really the shell environment variables or some other variables (I suspect it's rather the variables you can reference from Xcode project files, not shell environment).

Maybe we could check which generator is using CMake. If we're building an Xcode project, then set a macro which disables colors by default

That won't work for the (quite usual) case where you just take *.dylibs from Homebrew and put them into an Xcode project. The buildsystem can't make any assumption about how the resulting binary will get used.

Is there any other option which doesn't involve checking for environment variables?

Found this: https://stackoverflow.com/a/39292112 ... can you pull from the next branch and try things out? Both the Directory test and this color stuff should be fixed there (c8d67d9 and a3fb70a, for reference).

from corrade.

First of all, sorry for the late response 🙏

can you pull from the next branch and try things out? Both the Directory test and this color stuff should be fixed there

Yup, fixed :) The 77 tests passed without any errors, UtilityDebugTest detects it is running on an interactive shell, and UtilityDirectoryTest no longer gives any failed case. Also colors are enabled by default as it should be.

I think we can merge the next branch to master, close this and we're good to go!

from corrade.

I would be more confident in the change if we could be sure that Xcode detection really works 😅 Any chance you could install Xcode and try running one of the test executables in it?

from corrade.

Sure, I'm gonna install it and try if the code works there. Never used Xcode before, so I'll need some time 😅

from corrade.

Thank you for your time!

from corrade.