code --diff fails when filename contains an ampersand '&'

I am experiencing a rather puzzling error while trying to perform a diff on two files using Visual Studio Code from the command line. I have a text file in the cloud where I save some work related notes. I need to resolve conflicts with other clients editing the file. Usually this only happens during a loss of connection though somehow I find myself having to resolve a lot of them so between this and other uses of diff I will use the usual syntax. It looks something like this:

code --diff "R&D (cloud conflict 2-5-23).txt" "R&D.txt"

My filename happens to have a '&' in it and this command launches the usual 2-way diff in VS Code and reads through the first file name with no problem but doesn't read past the second '&' and the resulting diff tab in VS Code looks something like:

R&D (cloud conflict 2-25-23).txt <-> R

Where the right side "R" doesn't exist. So it would seem '&' needs to be processed literally.

No problem, let's see if backslash \ is an accepted escape parameter...

code --diff "R\&D (cloud conflict 2-5-23).txt" "R\&D.txt"

Nope. Same problem. 🤔 In fact this outputs something even stranger:

Code diff tab:
&D (cloud conflict 2-25-23).txt <-> R

with shell output:
'D.txt' is not recognized as an internal or external command,
operable program or batch file.

I also tried the carrot symbol '^' as an escape parameter to a similar effect. I just includes it in the first file and the editor still thinks the second file name is just "R".

The help file for the VS Code command line integration didn't have a lot to say about the --diff parameter other than a short description and I was hoping to get something about processing strings literally or escape characters. Perhaps another parameter that I need or maybe this has more to do with the shell in general.

I find it really strange that it can read the first full file name but breaks at the second '&'. Weirder still that if a supposed escape character is included in the second file name, it will omit that as well. 😵

For now all I can do is rename the file which is a bummer. 🤷‍♂️ I have VS Code version 1.75.0 on Windows 10 Home latest version/build and I'm using PowerShell version 5.1.19041.2364.

Edit: The issue definitely appears to be PowerShell related as it turns out. I was finally able to run this command successfully in a regular command prompt. (Simply typing "cmd" and Enter into the PowerShell window before running the diff command). Unfortunately, I happen to be running this command as part of PowerShell script. I may have to figure out how to run a CMD command from inside my PowerShell script if that is at all possible. I'm not sure. 🤔 If not, I need to figure out what exactly PowerShell is doing to my command when it reaches the '&' character.

<!-- language-all: sh -->

tl;dr

You need a workaround:

cmd /c 'code --diff "R&D (cloud conflict 2-5-23).txt" "R&D.txt"'

Alternatively, using --%, the stop-parsing token:

code --diff "R&D (cloud conflict 2-5-23).txt" --% "R&D.txt"

• Note: --% comes with fundamental limitations, notably the inability to reference PowerShell variables - see this answer.

Background information:

• The root cause is that code is implemented as a batch file (code.cmd) and that cmd.exe, the interpreter that executes batch file inappropriately parses its list of arguments as if they had been submitted from INSIDE a cmd.exe session.

• PowerShell, which - of necessity - has to rebuild the process command line behind the scenes on Windows after having performed argument parsing based on its rules, and - justifiably - places "R&D.txt" as verbatim R&D.txt on the process command line, given that the argument value contains no spaces.

• The result is that cmd.exe interprets the unquoted R&D.txt argument on its command line as containing metacharacter &, which is its command-sequencing operator, causing the call to break.

• Given that cmd.exe, the legacy Windows shell, is unlikely to receive fixes, the actively maintained PowerShell (Core) 7+ edition could as a courtesy compensate for cmd.exe's inappropriate behavior.

  • Doing so has been proposed in GitHub issue #15143, but, alas, it looks like these accommodations will not be implemented.