Respect console's color settings (on Powershell on windows)

[be5invis]

I use npm on Powershell, but npm changed the console's background color.

[isaacs]

What does npm --versions report? I think this was fixed in a recent node build. Perhaps update?

[be5invis]

1.1.16 from Node 0.6.15

[stdcall]

1.1.24, same issue.

[isaacs]

@stdcall npm --versions, plural. I'm looking for the node version.

[stdcall]

C:\Users\Nikolay> npm --versions
{ node: '0.6.19',
v8: '3.6.6.25',
ares: '1.7.5-DEV',
uv: '0.6',
openssl: '0.9.8r',
npm: '1.1.24' }

[salemhilal]

Any update on this? No matter what I do, npm changes the colors to light grey with slightly lighter grey text, and it makes it almost impossible to read.

[salemhilal]

I can't find a solution anywhere, so here's my slightly ghetto fix:

function np($arg1, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $arg8){

    npm $arg1 $arg2 $arg3 $arg4 $arg5 $arg6 $arg7 $arg8

    $a = (Get-Host).UI.RawUI
    $a.BackgroundColor = "DarkGray"    # Your background color here...
    $a.ForegroundColor = "Gray"        # and your foreground here.

    Write-Host "Colors corrected."
}

This doesn't fix node output, but at the very least it'll ensure that your colors are the same when you're finished.
I threw this in my profile and use np instead of npm. Anyone know of a way to pass all arguments?

[iignatov]

An alternative workaround is to disable the NPM colors with: npm set color false.

[xps]

This is still an issue in 1.3.21, why is this closed?

[salemhilal]

I was curious about that. I've since bought a mac, but npm set color false seems to work. Also, there's that really disgusting script I wrote a year ago. There's probably a way to get arguments as an array or something, but I didn't look into powershell scripting enough to find out.

[DanTup]

It doesn't just set the foreground to gray, it sets the background to black too. In a default PowerShell window (blue background), it looks really awful.

Disabling colours is a workaround, but then you lose a lot of readability in the ouput of npm commands.

[arteezy]

Can't believe this isn't fixed yet. I'm working on mac, but sometimes I need to go back to windows, and this tiny two-years-old bug really annoys me.

[domenic]

@arteezy pull request welcome!

[stereokai]

@othiym23 Any idea where in the code to start working on this?

[iarna]

@stereokai Search for 'color.bg' in the source, my suspicion is that if you remove all of the color.bgBlack calls it'll fix the issue. Failing that, you'll have to patch the ansicolors module.

Though briefly inspecting ansicolors, what it's doing what would normally be the right thing, if you look here:

http://en.wikipedia.org/wiki/ANSI_escape_code#graphics

It's sending code 39 to restore foreground color and 49 to restore background color. That this is failing in powershell implies that powershell doesn't properly support ansi. =( It almost certainly supports 0 to restore EVERYTHING to the defaults, you'll just have to figure out how to issue that at the right time...

[bradisbell]

For what it's worth, this isn't purely a PowerShell problem. I discovered the other day that if I customize my Command Prompt shortcut's colors, but then change the global Command Prompt colors, NPM will use the global colors. The colors are then permanently changed once NPM is done running.

npm --versions

{ http_parser: '1.0',
  node: '0.10.30',
  v8: '3.14.5.9',
  ares: '1.9.0-DEV',
  uv: '0.10.28',
  zlib: '1.2.3',
  modules: '11',
  openssl: '1.0.1h',
  npm: '1.4.21' }

[stereokai]

@iarna There only 2 calls to color.bgBlack: https://github.com/npm/npm/search?utf8=%E2%9C%93&q=color.bg

I don't think these are the problem. Perhaps incorporating something like this could be a solution:
https://github.com/adoxa/ansicon ?

[AncientSwordRage]

👍

[stereokai]

@iarna Any ideas (please see my previous comment)

[Ciwan1859]

This was first reported in April 2012! Over three years and still no fix :( This bug is annoying.

[stereokai]

@iarna @isaacs

Just because you guys use Macs doesn't take away from how annoying this bug is. And even if this issue doesn't seem to broadcast significance to you, doesn't mean you should let this one fall between the cracks. After all it's your product, and If this behavior would have occurred on OSX terminals, I am absolutely confident this bug would have been dealt with a long time ago.

6 months ago I also said I am willing to invest my time into this and even posted a practical comment, which I quote here below:

There only 2 calls to color.bgBlack: https://github.com/npm/npm/search?utf8=%E2%9C%93&q=color.bg

I don't think these are the problem. Perhaps incorporating something like this could be a solution:
https://github.com/adoxa/ansicon ?

Looking forward to your comment.

[domenic]

Looking forward to pull requests from those complaining.

[DanTup]

Looking forward to pull requests from those complaining.

What a poor attitude. Since when was "fixing bugs you find" a condition of using OSS? Why no appreciation for those taking time to report bugs to you and even do some investigation into the issue?

[Ciwan1859]

Surely domenic is joking! O.0

[domenic]

Not at all. Complaining on an issue tracker is not very helpful in fixing the issue. This is a known issue, tagged with patch-welcome, and just complaining that the npm team has been working on other issues instead of the particular one you care about is very bad open source ettiquete, compared to actually contributing to the project.

[Ciwan1859]

Thanks, with context, your previous post becomes understandable. My apologies, I was in a bad mood when I complained, I like my colours in PowerShell :) Will look and see if I can fix this damn thing.

[DanTup]

Complaining on an issue tracker is not very helpful in fixing the issue.

I think people are simply trying to express how frustrating this bug is, because it's clear it probably isn't affecting any of the contributors. Every time I use npm, I end up restarting PowerShell just to fix the colours. It makes npm seem unpolished and unloved.

compared to actually contributing to the project

I don't know, but I interpreted this comment:

There only 2 calls to color.bgBlack: https://github.com/npm/npm/search?utf8=%E2%9C%93&q=color.bg

I don't think these are the problem.

as "I can't figure out where this could be coming from and need some pointers". Sometimes something that is trivial to debug to someone that's familiar with the code is not so for someone else.

I'd love to have a go at fixing this but with limited time, it would probably take me a long time just to get the thing up and running in a way that would allow me to debug and investigate.

Having the time, motivation or ability to fix something is not an advertised condition of using OSS but if that's how things are then maybe it should be made clear. Nothing worse than committing to a technology to find the author(s) will not fix any bugs you report and expect you to do it yourself. There is an assumption that an active OSS project will have bugs that affect large numbers of people fixed; it's not unreasonable for people to show their support for a case (especially in an issue tracker that has no good way to vote, like Google Issues had stars, to help prioritise cases).

[floyd-may]

In the interest of keeping this positive and productive, I took a look at the code. After a brief perusal here, I suspect that this bug may need to be moved to the npmlog project. My guess is that the npmlog object should capture the current foreground and background colors upon its first interaction with the output stream, and be responsible for restoring them. Could one of the maintainers weigh in here, please?

[watilde]

How about to make default value of npm.color false when running on process.platform === "win32"...? https://github.com/npm/npm/blob/master/lib/npm.js#L347-L353

[floyd-may]

👎 npm.color = true is a good default if the terminal supports it. Turning them off by default will almost certainly ensure that this issue never gets fixed because fewer people would make noise about it.

Once upon a time I put a powershell function into my profile.ps1 that restores the FG and BG colors.

[floyd-may]

And down the rabbit hole we go. I'm suspecting that the ansi package that npmlog uses may be the actual culprit. I'll take a crack at a boiled-down repro in the next few days.

[Ciwan1859]

Thanks floyd, mcuh apprecaited.

[stereokai]

@DanTup 👍

@domenic

Not at all. Complaining on an issue tracker is not very helpful in fixing the issue. This is a known issue, tagged with patch-welcome, and just complaining that the npm team has been working on other issues instead of the particular one you care about is very bad open source ettiquete, compared to actually contributing to the project.

Excuse me? Have you actually paid attention to my... "rant"? I wasn't only complaining (though rightfully so, and in stark contrast to you), I actually had a go at this 6 months ago and was looking for some pointers from people who actually know the code. Like you.

I don't want to turn this into a personal thing or whatever. But you could might as well direct your comment about my "complaining, non-contributing attitude" to yourself.

@floyd-may

Once upon a time I put a powershell function into my profile.ps1 that restores the FG and BG colors.

Although not a fix to the bug, it's a very clever idea - well done!

And down the rabbit hole we go. I'm suspecting that the ansi package that npmlog uses may be the actual culprit. I'll take a crack at a boiled-down repro in the next few days.

That's what @iarna recommended me to look at last year. I have taken another thorough look at ansi, but I have a hunch that this is not where the problem is. I tend to lean towards her idea:

powershell doesn't properly support ansi. =( It almost certainly supports 0 to restore EVERYTHING to the defaults, you'll just have to figure out how to issue that at the right time...

[floyd-may]

@stereokai In reference to this:

powershell doesn't properly support ansi. =( It almost certainly supports 0 to restore EVERYTHING to the defaults, you'll just have to figure out how to issue that at the right time...

Here's an interesting tidbit from npmlog. It calls .reset() after every write, which leads me to thinking that the problem may lie with ansi's reset() function.

[floyd-may]

Actually, I just discovered something beautifully interesting. And frustrating as well. I put together a little sample app using ansi:

var ansi = require('ansi');

var ansiLogger = ansi(process.stderr);

ansiLogger.fg.red();
ansiLogger.bg.grey();

ansiLogger.write('colored output\n').reset();

Now, in ConEmu (my terminal of choice on Windows), this works fine:

However, if I use powershell.exe by itself, I get the derpy behavior:

So, IMHO, ansi (and, by extension, npmlog [and, by extension, npm]) is doing the Right Thing (tm) and resetting the colors. It just so happens that Powershell.exe's GUI on Windows doesn't properly interpret it.

You may consider switching to ConEmu (or something like it) rather than using powershell.exe as-is. Resizable window, tabs, etc. You will hate life less, and be less prone to internet trolling.

[mvas]

Updating to latest node version solves the issue

[iarna]

I can confirm that this does not happen in PowerShell for me any more with a current Node.js. I'm going to close this as resolved.

[stereokai]

@iarna Thank you.

[jarruda]

I'm running version 5.5.1 and seeing this behavior again when running inside of the VS Code integrated terminal with powershell.

I do not see it when running in a native Powershell terminal.

[floyd-may]

@jarruda I'd recommend running the sample app above that uses the ansi package and see what behavior you get. If you get the same behavior as your screenshot, then this probably needs to be taken to the VS Code issue tracker.