Change:
} else { (this.terminalService.configHelper as TerminalConfigHelper).mergeDefaultShellPathAndArgs(shellLaunchConfig); } <del> let shellArgs = shellLaunchConfig.args.slice(0); </del> <ins> let shellArgs = <string[]>shellLaunchConfig.args.slice(0); </ins> let toAdd: string[] = []; let commandLine = args && args.length > 0 ? `${command} ${args.join(' ')}` : `${command}`; if (Platform.isWindows) {

Discussion:
<!-- Do you have a question? Please ask it on ---create a new terminal with the following shell args ! Executing this on a folder that contains a folder results in the following error message: Using the following args (observer the additional quote around the command) results in the same error ! Executing this in a command shell () works: ! As does on powershell (without the extra double quotes): !
Could it be that the command line somehow get changed / corrupted until it is passed to the process.
I'm guessing this is an issue with the  function in node-pty.
Could be, but please note that I pass one arg for the command line. So instead of ["dir", "test folder"] which would need proper escaping I pass [""dir "test folder"""] which is exactly one arg and already proper escaped.
I inspected the 's command line when spawned and it looks like this (removed /c to keep it alive) ! Looks like some double quotes got escaped :-)
Actually I didn't quote the command correctly. It should be quoted so the JS string in debugger looks like . Passing this to the terminal still results in  characters on the command line: ! Executing from a powershell command prompt results in ! which looks correct (no  to escape ")
I think I can reproduce this in node-pty by running the following: Output: A similar example however works fine on Linux using
Fixed upstream , still want to verify it within VS Code before pushing it.
this should be good to go now, you'll want to update node_modules/node-pty and then set as a that will be used as is. Example: Let me know if you have any issues.
why is the string option only supported under Windows. You need to escape under Mac and Linux as well. Under these OSes there are even three different kind of space escapings so the code can't simply take one (see ). IMO we need to let users control this.
I was under the impression this only really applies to cmd/Windows. From Do you have a particular use case that fails in on macOS or Linux?

may be I am not understanding it correctly but here is what I like to allow users do to for an example to run a command in a shell that takes args with spaces in it: : escpae using  for a single space : escape using weak quoting : escape using strong quoting How would I pass such a command line to a shell I start under Mac / Linux?
Aren't they all basically the same thing? Is there a reason for using anything other than ? That's all the terminal shell/shellArgs support and I haven't seen any complaints so far.
According to " and ' have a very different semantic. So is there a way for me to pass args and tell the shell to not do any quoting. So if I pass will it respect the quoting and leave the string untouched?
Is this what you mean? ! Force in dev build. Add this to !
Yes. So how would I pass this to a shellLaunchConfig in code in terms of args? Like this: ["-c", "ls -ls 'a b'"] and not one string args like under Windows ?
Yes, and map 1:1 to the and
thanks!