Fix color printing and --verbose #1212

AustinWise · 2016-02-03T23:20:12Z

I noticed that the escape codes are being printed instead of colors on Windows. There were a couple problems:

When running intrinsic commands, the AnsiPassThrough was being enabled. This caused the escape codes to never be processed for intrinsic commands.
Reporter.Write did not transform escape codes into colors. The Command uses this method to forward some output.

Calling ShouldPassAnsiCodesThrough() for the side effect of reading the environmental variable seems a little lame. Perhaps instead Command.CreateDotNet should always set this variable? I'm not sure if Microsoft.DotNet.Cli.Utils is meant for consumption by externals tools as a means of invoking dotnet.exe, so I did not do it there.

dnfclas · 2016-02-03T23:20:17Z

Hi @AustinWise, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.

TTYL, DNFBOT;

src/dotnet/Program.cs

@@ -140,6 +140,8 @@ private static int ProcessArgs(string[] args)
            {
                // mimic the env variable
                Environment.SetEnvironmentVariable(CommandContext.Variables.Verbose, verbose.ToString());
+                // Use the current value of AnsiPassThru but make sure child processes have it set to true.
+                CommandContext.ShouldPassAnsiCodesThrough();


AustinWise · 2016-02-04T22:43:31Z

I changed the way the environmental variable is read to be explicit, instead of calling a getter method for the side effect of lazy initialization.
I also expanded the scope of this pull request a little bit by making sure the verbose environmental variable is inherited by all child processes. Currently only the first process is getting it and it will be overwritten in any child processes.

src/dotnet/Program.cs

+                Environment.SetEnvironmentVariable(CommandContext.Variables.Verbose, verbose.ToString());
+            }
+            //This process should inherit AnsiPassThrough or use the default of false.
+            CommandContext.InitializeAnsiPassThroughFromEnvironment();


AustinWise · 2016-02-05T01:03:07Z

For reference, this is what it looks like before this change:

And after:

Note the funny looking "←[33m" text in the before picture.

AustinWise · 2016-02-05T02:26:54Z

I push a new commit that just applies the environmental variable to all children created with the Command class. I think this is the right place to set the variable as the Command does the output forwarding that depends on this variable being set in children.

src/Microsoft.DotNet.Cli.Utils/Command.cs

@@ -28,6 +28,7 @@ private Command(CommandSpec commandSpec)
                RedirectStandardError = true,
                RedirectStandardOutput = true
            };
+            psi.Environment[CommandContext.Variables.AnsiPassThru] = bool.TrueString;


brthor · 2016-02-05T21:19:50Z

This LGTM.

We are having some issues with tests on the CI right now so we'll hold off on merging for the moment.

I'd also like to see how this interacts with the new streamforwarder changes in #1240. I don't expect any issues but there is potential.

AustinWise · 2016-02-05T21:38:17Z

If #1240 get's merged first I'll rebase ontop of it and try it out. It does not look like it would cause any problem.
Thanks for reviewing my changes!

AustinWise · 2016-02-09T21:10:56Z

I rebased onto the tip of 1.0.0 to fix the merge conflicts.

AustinWise · 2016-02-11T21:55:46Z

I rebased and it seems like #1364 has fixed the build problems.
I tested out my changes the colors are still fixed.

brthor · 2016-02-11T23:08:31Z

I think we should merge this today.

@anurse want to take a quick look?

analogrelay · 2016-02-11T23:11:05Z

LGTM too. ANSI pass-through should be able to go away once we change Command.cs to only redirect stdout/stderr when we actually want to capture the output. It's only there because Windows uses APIs to manage Console Colors rather than ANSI codes :)

AustinWise · 2016-02-12T00:22:24Z

Since ANSI pass through is temporary, when I rebased I did not add the new parameter to ICommand.

As an aside, during testing I discovered that Windows 10 v1511 added support for these ANSI codes.

brthor · 2016-02-12T20:16:00Z

@dotnet-bot Windows_NT Debug Build please

AustinWise · 2016-02-12T23:01:29Z

@brthor Odd, I don't understand why ProcessStartInfo.Enironment stopped working on just Windows. Do you have any ideas?

'ProcessStartInfo' does not contain a definition for 'Environment'

src/Microsoft.DotNet.Cli.Utils/Command.cs

@@ -149,6 +149,7 @@ public ICommand ForwardStdOut(TextWriter to = null, bool onlyIfVerbose = false)
                if (to == null)
                {
                    _stdOut.ForwardTo(writeLine: Reporter.Output.WriteLine);
+                    _process.StartInfo.Environment[CommandContext.Variables.AnsiPassThru] = bool.TrueString;


brthor · 2016-02-12T23:25:34Z

@AustinWise Not sure, seems weird only on Windows. Will need to investigate

Only apply the ANSI passthrough for child commands. Otherwise the escape codes are printed to the console on Windows Make Report.Write process escape codes so that forwarded output will have its escape codes processed. Also make verbose be inherited by all child processes.

AustinWise · 2016-02-13T01:14:45Z

@dotnet-bot Windows_NT Debug Build please

AustinWise · 2016-02-13T01:44:57Z

@brthor I fixed the compile error. As part of doing that I put the ansiPassThrough back on Command and added it to ICommand.

Fix color printing and --verbose

TheRealPiotrP · 2016-02-13T07:40:18Z

Thanks @AustinWise!

AustinWise · 2016-02-13T09:27:58Z

@piotrpMSFT Thanks for @brthor reviewing my code. I'm looking forward to seeing pretty colors in my terminal again!

dnfclas added the cla-already-signed label Feb 3, 2016

leecow removed the cla-already-signed label Feb 3, 2016

livarcocc reviewed Feb 3, 2016
View reviewed changes

AustinWise changed the title ~~Fix color printing on Windows.~~ Fix color printing and --verbose Feb 4, 2016

brthor reviewed Feb 4, 2016
View reviewed changes

brthor reviewed Feb 5, 2016
View reviewed changes

brthor reviewed Feb 12, 2016
View reviewed changes

AustinWise added 2 commits February 12, 2016 15:52

Fix build break on Windows.

6957303

TheRealPiotrP pushed a commit that referenced this pull request Feb 13, 2016

Merge pull request #1212 from AustinWise/fixColors

e8ef94e

Fix color printing and --verbose

TheRealPiotrP merged commit e8ef94e into dotnet:rel/1.0.0 Feb 13, 2016

AustinWise deleted the fixColors branch February 13, 2016 09:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix color printing and --verbose #1212

Fix color printing and --verbose #1212

AustinWise commented Feb 3, 2016

dnfclas commented Feb 3, 2016

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

AustinWise commented Feb 4, 2016

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

AustinWise commented Feb 5, 2016

AustinWise commented Feb 5, 2016

This comment was marked as spam.

This comment was marked as spam.

brthor commented Feb 5, 2016

AustinWise commented Feb 5, 2016

AustinWise commented Feb 9, 2016

AustinWise commented Feb 11, 2016

brthor commented Feb 11, 2016

analogrelay commented Feb 11, 2016

AustinWise commented Feb 12, 2016

brthor commented Feb 12, 2016

AustinWise commented Feb 12, 2016

This comment was marked as spam.

brthor commented Feb 12, 2016

AustinWise commented Feb 13, 2016

AustinWise commented Feb 13, 2016

TheRealPiotrP commented Feb 13, 2016

AustinWise commented Feb 13, 2016

Fix color printing and --verbose #1212

Fix color printing and --verbose #1212

Conversation

AustinWise commented Feb 3, 2016

dnfclas commented Feb 3, 2016

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

AustinWise commented Feb 4, 2016

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

AustinWise commented Feb 5, 2016

AustinWise commented Feb 5, 2016

This comment was marked as spam.

This comment was marked as spam.

brthor commented Feb 5, 2016

AustinWise commented Feb 5, 2016

AustinWise commented Feb 9, 2016

AustinWise commented Feb 11, 2016

brthor commented Feb 11, 2016

analogrelay commented Feb 11, 2016

AustinWise commented Feb 12, 2016

brthor commented Feb 12, 2016

AustinWise commented Feb 12, 2016

This comment was marked as spam.

brthor commented Feb 12, 2016

AustinWise commented Feb 13, 2016

AustinWise commented Feb 13, 2016

TheRealPiotrP commented Feb 13, 2016

AustinWise commented Feb 13, 2016