Vscode: Failed to launch external program tsc -w -p .. spawn tsc ENOENT

[normalser]

• VSCode Version: Version 1.3.0-insider (1.3.0-insider) d0c2b891903d73e83dcdc7786398ebfa764fc4ee
• OS Version: OSX 10.11.5

Steps to Reproduce:

1. Open VSCode insider from Finder (not from terminal)
2. Try to run build task (that is using tsc -w)
3. I'm using nvm so proper PATH needs to be set eg . ~/.nvm/...

This is similar to https://github.com/Microsoft/vscode/issues/7343 or even identical. Commit https://github.com/Microsoft/vscode/commit/1a7c54e2678107a72f8546fb9319ff2f6dd1487d does not fix this issue for me.

When I start VSCode from Finder and open devtools then process.env.PATH == "/usr/bin:/bin:/usr/sbin:/sbin". When I start VSCode from terminal then it has my proper process.env.PATH == "/Users/wallverb/.nvm/versions/node/v4.2.2/bin:/opt/local/bin:.........."

When I run this code in devtools:

const electron = "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron";
const cp = require('child_process');
const env = Object.assign({}, process.env, {
    ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1',
    ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p 'JSON.stringify(process.env)'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
    detached: true,
    stdio: ['ignore', 'pipe', process.stderr],
    env,
    encoding: 'utf8'
});
console.log(result.stdout.match(/"PATH":"(.*?)"/)[1])

// const strip = s => s.replace(/[\u001b\u009b][[()#;?]*(?:[0-9]{1,4}(?:;[0-9]{0,4})*)?[0-9A-ORZcf-nqry=><]/g, '').replace(/\u001b\].*?\u0007/g, '');
//console.log(JSON.parse(result.stdout));  // would throw parse error

Then proper path is returned : "/Users/wallverb/.nvm/versions/node/v4.2.2/bin:/opt/local/bin:.........."

but the problem is that my interactive shell returns some "intro message" (eg. zsh -ilc env will return INTRO_MESSAGE\nwalverb which will of course break JSON.parse() in above code. I wonder why is 1.2.0 working fine and it's only problem with 1.3.0-insider

[niieani]

I can confirm this is a bug for any commands, not only build tasks, but also run commands. Commands that should be available under PATH seem not to be found under macOS.

[weinand]

First a recap of this OS X problem:

If an application is launched via the Finder (e.g. by doubleclicking), it does not automatically inherit your existing bash environment. So if you have set an environment variable like PATH in .bash_profile (or any other profile), this value is not available in the application (or any of its sub processes).

VS Code tries to work around this by launching a shell that reads the .bash_profile and then returns the environment variables so that VS Code can merge them into the environment that gets passed along.

The problem is that any customisation of the used shell might affect how the list of environment variables is returned. This makes parsing difficult. The const strip = s => s.replace(/[\u001b\u009b... from above tries to cope with that but it seems that your case is (again) different and not covered by the regular expression.

@joaomoreno I think we have to find a more sustainable way to handle this.

As workaround you can launch VS Code from the command line. In this case PATH will be what you expect.

You can install the 'code' shell command from within VS Code:

After that you can launch VS Code from the command line with code (or code-insiders).

[niieani]

@weinand Note that I don't use bash, but fish as my default shell. .bash_profile is not the only canonical way to extend PATH env under OS X. There's also the /etc/paths.d directory which is more universal. Perhaps as a workaround VSCode could launch the default shell, extract the PATH, set it and close it immediately?

[normalser]

But why does it work fine with VSCode 1.2.0 ?

[joaomoreno]

It worked _almost_ fine: #6375.

We can maybe wrap the JSON object, as suggested by @weinand.

@wallverb Does something like this work?

const electron = "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron";
const cp = require('child_process');
const mark = 'MARK123';
const env = Object.assign({}, process.env, {
    ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1',
    ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
    detached: true,
    stdio: ['ignore', 'pipe', process.stderr],
    env,
    encoding: 'utf8'
});
const raw = new RegExp(mark + '(.*)' + mark).exec(result.stdout)[1];
console.log(JSON.parse(raw));  // should not throw parse error

[normalser]

Yessss @joaomoreno - trick with mark works like a charm

[niieani]

@joaomoreno I have iTerm2 integration and this one works for me too!

[joaomoreno]

Alright guys, thanks for your replies, we'll go with this then. Props to @weinand for coming up with the idea!

[bmingles]

Any chance that running non-interactively would fix this? In my .bash_profile I have conditional echo statements eg.
if [[ $- == *i* ]] then echo 'foo' echo 'bar' fi

If I remove the -i flag cp.spawnSync(process.env.SHELL, ['-lc', command] things seem to parse.

[joaomoreno]

@bmingles The fix will be instead: wrapping the JSON object with a sequence of bytes that are unlikely to occur in the rest of the output.

[bmingles]

@joaomoreno I have confirmed that your proposed solution fixes my issue as well. Thanks.

[normalser]

Maybe it could go to June 2016 milestone ? Seems like I'm not alone with that issue.

[joaomoreno]

@wallverb Had it been a little earlier I would've agreed with you, but here's what I'm thinking:

• It affects people that
  
  
  
  • Run on *nix, and
  
  
  • Have customised their .bash_profile, making them power users who
  
  
  • are likely to be on the insider release any way, which will get the fix this week.
  
  
• Not all output from bash breaks this, since there is already ANSI escape code protection, #7343.
• There is a workaround: launch code from the command line. Another one is: use the insiders build.
• June's release is planned for today.

Given all that, I'm forced to not include this for June, but for July. I just hope I'm not being too optimistic. 🙈

[NinoFloris]

When will this fix be rolled out?

As I have both iTerm shell integration and powerline integration interfering with the proper extraction of the env.

Thanks for the fix though!

[bmingles]

@NinoFloris I missed this initially in the thread, so just wanted to re-mention that opening vscode from the terminal circumvents the bug. At least it did for my scenario.

[victoriafrench]

This is back in 1.12.1 also affecting node, flow, npm. Did not happen in 1.12.0

[pjpmccarthy]

I'm getting the same error on Windows, which is surprising. What is "Composer depenncy manager" as shown in the error message?

[sinadarvi]

• VSCode Version: Version 1.13.1
• OS : Windows 10

i'm have a same issue on windows too. is it still a bug ?

[weinand]

@sinadarvi please create a new issue.

[kylerdanielster]

I am having the same issue on Linux Mint 18.1 with VSCode 1.13.1 as well. I could not find a new issue, anyone confirm that a new issue had not be opened? I will write one up if one has not been opened.

Thanks

[weinand]

@kylerdanielster please create new issue with detailed steps.