System.ArgumentNullException thrown for colored console output on Mono

[Dzoukr]

Ok, this is not actually FAKE`s fault, but right now I do not know where to put this important information, which could save few hours for other developer. Please, take this as something worth documenting (i can send PR, if you would hint me where to put this information):

When running FAKE on Mono (version 4.4.2) on Ubuntu 12.04/14.04, this error occures:

Unhandled Exception:
System.ArgumentNullException: Value cannot be null.
Parameter name: format
  at System.ParameterizedStrings.Evaluate (System.String format, FormatParam[] args) <0x7f0d4902ab20 + 0x001e7> in <filename unknown>:0 
  at System.TermInfoDriver.ChangeColor (System.String format, ConsoleColor color) <0x7f0d490256b0 + 0x0010e> in <filename unknown>:0 
  at System.TermInfoDriver.set_ForegroundColor (ConsoleColor value) <0x7f0d490258b0 + 0x00037> in <filename unknown>:0 
  at System.ConsoleDriver.set_ForegroundColor (ConsoleColor value) <0x7f0d490136e0 + 0x00048> in <filename unknown>:0 
  at System.Console.set_ForegroundColor (ConsoleColor value) <0x7f0d49012830 + 0x0000c> in <filename unknown>:0 
  at Fake.TraceListener+ConsoleTraceListener.writeText (Boolean toStdErr, ConsoleColor color, Boolean newLine, System.String text) <0x407f35e0 + 0x00052> in <filename unknown>:0 
  at Fake.TraceListener+ConsoleTraceListener.Fake-TraceListener-ITraceListener-Write (Fake.TraceData msg) <0x40216dc0 + 0x000bc> in <filename unknown>:0 
  at [email protected] (ITraceListener obj) <0x40216d90 + 0x00025> in <filename unknown>:0 
  at System.Collections.Generic.List`1[T].ForEach (System.Action`1 action) <0x7f0d48cdf440 + 0x0007e> in <filename unknown>:0 
  at Fake.TraceListener.postMessage (Fake.TraceData x) <0x40216c40 + 0x0010c> in <filename unknown>:0 
  at <StartupCode$FAKE>.$Program.main@ () <0x40184d90 + 0x01171> in <filename unknown>:0 

To fix this, you have to set environment property SET TERM=xterm-color ! After setting this, everything works great.

Maybe this environment property could be auto-set by FAKE when running on Mono (just idea).

[forki]

Auto.Setting sounds great. Can you try to send a PR?

2016-08-12 20:53 GMT+02:00 Roman Provazník [email protected]:

Ok, this is not actually FAKE`s fault, but right now I do not know where
to put this important information, which could save few hours for other
developer. Please, take this as something worth documenting (i can send PR,
if you would hint me where to put this information):

When running FAKE on Mono (version 4.4.2) on Ubuntu 12.04/14.04, this
error occures:

Unhandled Exception:
System.ArgumentNullException: Value cannot be null.
Parameter name: format
at System.ParameterizedStrings.Evaluate (System.String format, FormatParam[] args) <0x7f0d4902ab20 + 0x001e7> in :0
at System.TermInfoDriver.ChangeColor (System.String format, ConsoleColor color) <0x7f0d490256b0 + 0x0010e> in :0
at System.TermInfoDriver.set_ForegroundColor (ConsoleColor value) <0x7f0d490258b0 + 0x00037> in :0
at System.ConsoleDriver.set_ForegroundColor (ConsoleColor value) <0x7f0d490136e0 + 0x00048> in :0
at System.Console.set_ForegroundColor (ConsoleColor value) <0x7f0d49012830 + 0x0000c> in :0
at Fake.TraceListener+ConsoleTraceListener.writeText (Boolean toStdErr, ConsoleColor color, Boolean newLine, System.String text) <0x407f35e0 + 0x00052> in :0
at Fake.TraceListener+ConsoleTraceListener.Fake-TraceListener-ITraceListener-Write (Fake.TraceData msg) <0x40216dc0 + 0x000bc> in :0
at [email protected] (ITraceListener obj) <0x40216d90 + 0x00025> in :0
at System.Collections.Generic.List1[T].ForEach (System.Action1 action) <0x7f0d48cdf440 + 0x0007e> in :0
at Fake.TraceListener.postMessage (Fake.TraceData x) <0x40216c40 + 0x0010c> in :0
at <StartupCode$FAKE>.$Program.main@ () <0x40184d90 + 0x01171> in :0

To fix this, you have to set environment property SET TERM=xterm-color
! After setting this, everything works great.

Maybe this environment property could be auto-set by FAKE when running on
Mono (just idea).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1355, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNE_az8KVLjto3L5bcMdtEa8eXssbks5qfMFAgaJpZM4JjXBd
.

[rmunn]

Related: microsoft/vscode#9681

TL;DR: The right value to set is almost certainly xterm-256color, but xterm-color should work too. More details about WHY this is happening can be found in that VS Code issue.

[Dzoukr]

Well, after two accepted PRs #1355 and #1363 , I am quite desparate. Setting property on CI (ubuntu) servers still doesn´t work properly. When I try test like this:

Target "TestMono" (fun _ ->
    tracefn "MONO IS %b" EnvironmentHelper.isMono
    tracefn "UNIX IS %b" EnvironmentHelper.isUnix
    tracefn "TERM = %s" <| System.Environment.GetEnvironmentVariable("TERM")
)

TERM property is set ok (inside TestMono Target) to xterm-256color (as it should by PR), BUT it seems like this property is set after first usage of System.TermInfoDriver.ChangeColor, so this test actually fails (I had to pre-set ENV variable with xterm-color to run it) . Maybe I can`t see something completely obvious? @forki / @rmunn do you have any idea?

[rmunn]

I did some pretty extensive research when writing that microsoft/vscode#9681 issue, but I never found out how to change the terminfo setting from inside a process. If you're starting another process (as VS Code is with the integrated terminal) then you can set $TERM and it will stick. But $TERM gets read very early in the process of launching a new process, well before any code that you would get to run. Maybe there's a Unix syscall of some kind that you could use to change the terminal type that it thinks you're running in, but actually I kind of doubt it. Unix was set up to trust the terminal to know best what kind of terminal it is. And gnome-terminal has been horribly broken for years, reporting that it's just a dumb xterm instead of properly reporting that it's an xterm-color or, better yet, an xterm-256color. (To be fair to the GNOME developers, they had what they thought was a good reason -- working around bugs in certain Linux distros -- but it was still a terrible decision.)

The right answer is to put something like the following in your .bashrc file, right above where it checks the value of $TERM and sets color_prompt accordingly:

# Work around broken gnome-terminal setting
if [ "$TERM" == "xterm" ]; then
    if [ "$COLORTERM" == "gnome-terminal" ]; then
        # Set a value that will let color output work properly
        export TERM=xterm-256color
    fi
fi

However, that only works on YOUR machine, and won't work widely. (Also note that the $COLORTERM detection I did will STOP working as of Ubuntu 15.04, because the GNOME folks dropped the non-standard $COLORTERM thing. Hopefully it was around the time that they stopped calling themselves xterm.)

The only thing that comes to mind is to detect this scenario (by checking the value of $TERM and, if you're on Ubuntu 15.04 or earlier, the value of $COLORTERM, though that check might not be worth it) and printing out a warning message to the user:

NOTE: Color output has been disabled because of a bug in GNOME Terminal. To work around this bug, edit your .bashrc file and add the following:

And then put in the if [ "$TERM" == "xterm" ]; then export TERM=xterm-256color; fi lines. (Don't bother with checking $COLORTERM, I don't think it's worth it. There isn't a single modern terminal emulator these days that won't do the right thing with an xterm-256color termcap.)

But as far as setting it correctly from within FAKE, I'm afraid you're probably hosed. I think you'll have to detect the problem, disable color if it's detected, and tell the user how to fix it by editing their .bashrc file.

[Dzoukr]

Wow, thanks @rmunn for great explanation! Now it seems like we cannot fix this "from inside", but maybe we could just check for exception in TraceListener+ConsoleTraceListener.writeText and give some hint to user like "Colored output is not supported on your operation system. Please set environment property TERM=xterm-256color"

What is your opinion about this, @forki ?

[forki]

I have no idea. Please send pr to make it work like you guys think it's
appropriate. I'm on Windows...

Am 22.08.2016 4:26 nachm. schrieb "Roman Provazník" <
[email protected]>:

Wow, thanks @rmunn https://github.com/rmunn for great explanation! Now
it seems like we cannot fix this "from inside", but maybe we could just
check for exception in TraceListener+ConsoleTraceListener.writeText and
give some hint to user like "Colored output is not supported on your
operation system. Please set environment property TERM=xterm-256color"

What is your opinion about this, @forki https://github.com/forki ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1355 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADgNBxqguiWp0UDLwYdXEddwUkG9an8ks5qibGvgaJpZM4JjXBd
.