ANSI codes appear in process.env.PATH after fix-path

[sindresorhus]

ANSI codes appear in process.env.PATH after fix-path

[silverwind]

Interesting. What does process.env.TERM end up being when you see the ANSI codes and which shell and OS is this on?

[SamVerschueren]

• TERM=xterm-256color
• shell: bash

[silverwind]

Pushed sindresorhus/shell-path@1703975, can you give that one a try?

[silverwind]

Note: I don't understand what \u001b(B\u001b[m does, but I guess it won't hurt if we strip it. Maybe @Qix- has some insight?

[SamVerschueren]

Note: I don't understand what \u001b(B\u001b[m does

Neither do I :).

Will try it tomorrow, just closed my laptop but guess it'll work as strip-ansi was the hotfix I used in my code.

[sindresorhus]

Couldn't we just disable colors by for example changing echo "$PATH" to something like TERM=dumb; echo "$PATH"?

[SamVerschueren]

The less dependencies, the better. Will try it out tomorrow!

[SamVerschueren]

Couldn't resist, had to know :).

Tried this:

function pathFromSudoSync() {
    try {
        return childProcess.execSync('TERM=dumb; sudo -Hiu ' + user + ' echo "$PATH"', opts).trim();
    } catch (err) {
        // may fail with 'sudo: must be setuid root'
        return '';
    }
}

But still returns a string with color codes. This is the .bash_prompt I use btw. Maybe this offers some more insights.

[Qix-]

Not sure what (B is but [m is analogous to [0m. I don't think it's standard.

[silverwind]

Pretty sure that \u001b(B\u001b[m has nothing to do with color at least.

$ node -e 'console.log("\u001b(B\u001b[mHi!")'
Hi!

[Qix-]

[0m (or [m) means reset render. \u001b(B seems strange. I'll have to research. I can take a look later; my attention is on the mass shooting right now, heh.

[SamVerschueren]

I did some more investigation in the dot-file. It's actually this line that is the cause of all this.

[silverwind]

Googling the first three bytes 0x1B 0x28 0x42 tells me it's some kind of japanese escape sequence?

http://www.sxemacs.org/docs/internals/JIS7.html

     Escape sequence   ASCII equivalent   Meaning
     ---------------   ----------------   -------
     0x1B 0x28 0x4A    ESC ( J            invoke Japanese-JISX0201-Roman
     0x1B 0x28 0x49    ESC ( I            invoke Japanese-JISX0201-Kana
     0x1B 0x24 0x42    ESC $ B            invoke Japanese-JISX0208
     0x1B 0x28 0x42    ESC ( B            invoke Printing-ASCII

[silverwind]

Confirming it's the output of tput sgr0, which appears to be a color reset that also seems to reset japanese terminals to regular ASCII mode. I still think my fix is worth to keep, as TERM=dumb does probably not take care of \u001b(B.

> child_process.execSync('tput sgr0', {encoding: 'utf8'})
'\u001b(B\u001b[m'

[silverwind]

TERM=dumb does remove both sequences for me on both OSX and Linux. Now if only I could get this execSync to work 😕

> child_process.execSync("tput sgr0", {encoding: 'utf8', env: process.env})
'\u001b(B\u001b[m'
> process.env.TERM = 'dumb'
'dumb'
> child_process.execSync("tput sgr0", {encoding: 'utf8', env: process.env})
Error: Command failed: tput sgr0

[SamVerschueren]

When executing that I noticed the shell of child_process is sh. Tried changing that to bash but didn't seem to work either.

[Qix-]

That's not uncommon, unless you specifically invoke the shell of your choice, you're going to get /bin/sh.

[silverwind]

Won't matter in which shell that sudo executes. The -i option does "run the shell specified by the target user's password database entry as a login shell".

[sindresorhus]

Just realized I never published the strip-ansi workaround. Done now. Keeping this issue open as I'd still like to find a better fix. Open to additional suggestions.