Project.exec, Linux, and color terminals

(Jason Griffith) #1


We’re trying to execute an xbuild code-analysis function using project.exec() and can’t seem to get xbuild to find it acceptable to output color codes. We’d sure love it if it did.

I’m ssh’d in to my machine and have set TERM to “xterm-color”. I can run the command from the command-line and it works swell:

/usr/bin/xbuild /property:Configuration=CodeAnalysis “/property:Platform=Any CPU” /verbosity:minimal /target:Build /p:CommandLineDefineConstants=Linux PathToSolutionFile

All errors and warnings show up in red and yellow respectively. This is really what we’re after, given that xbuild only uses STDOUT… We’d love to use these colors to interpret error-level per line.

Run through project.exec, the same command will not output color. I am not a Linux guru, but I understand that the called program is what determines whether it is being run in a terminal and is what chooses whether or not to use color codes.

Question is: Can Gradle execute subprocesses as if they were run in a terminal or in a way that the called program can’t tell it’s run in a subprocess? Is this something in Gradle’s power?


It's subprocesses all the way down - project.exec, wrapper scripts, and argument-handling
(Sterling Greene) #2

Hey @JGriffith

You’re right that Gradle doesn’t have much control over this. This is going to be tough to do with the way xbuild decides to use colors:

xbuild won’t use colors if it doesn’t detect a console. For other tools, they either always use colors or have a flag that enables colors unconditionally.

I’m not sure what the release schedule is like for mono, but I think we’d need a flag or env var that forces colors, regardless of the tty, to make this reliable.

(Jason Griffith) #3

Thanks for digging in so deep, Sterling!

MSBuild for Windows has an “always use colors” flag (that, as a bonus, actually works!) It looks like xbuild is moderately-recently deprecated in favor of msbuild under Linux, so here’s hoping the always-color flag is present and works there too.

Was hopeful there was some way to set up a subprocess to be all, “Yeah, I’m totally a terminal.” The ‘script’ command seems to be able to manage running a sub-process as if it were run in a terminal, but I have no idea what dark magic fuels that power.

Sounds like we’re going to have to hold tight and hope that the XBuild->MSBuild transition (whenever that happens) provides the flag to always use color.

Thanks again!

(Sterling Greene) #4

I tried to get script to work a bit, but I gave up once I realized:

  1. I’d need a different set of arguments (or script alternative) for Windows, macOS and Linux
  2. Running via script makes it hard for Gradle to know the true state of the other process, which can cause other problems (like orphaned processes on Windows or hangs due to the grandchild process dying).

It looks like the “always use color” flag doesn’t check any other environment information for msbuild:

(Jason Griffith) #5

Cool! Thanks again, Sterling. Your finding the precise bits of xbuild/msbuild code is really impressive :slight_smile:

And informative! Looks like I’ll be adding a //TODO here and we’ll address it once we’ve migrated to msbuid.

(“Yeah, yeah, patience… How long will that take?” - Ed Grubermann)