Forward slash in env paths can break some tools

[avih]

Some tools, notably cmd.exe commands, have issues with forward slashes in values.
e.g. consider the resulting batch file here:

printf %s\\n 'mkdir %APPDATA%\foo' > test.bat
./test.bat
C:\test>mkdir C:/Users/<user>/AppData/Roaming\foo
The syntax of the command is incorrect.

cmd.exe itself even refuses to run if it's invoked with forward slashes in its own path, e.g. the value of $COMSPEC if it had forward slashes like APPDATA has.

busybox-w32 does convert backslashes in PATH and few more (APPDATA, possibly others) to forward slashes.

Other than for (questionable?) aesthetic reasons, is there a value in converting backslashes to forward slashes in ENV?

If yes, shouldn't it be converted back to backslashes when executing an application? as demonstrated, some might have issues with forward slashes.

EDIT
I'm noticing it's not a general busybox-w32 thing, but rather an ash thing (and possibly more, but not all). E.g. in cmd.exe prompt, this prints path with backslashes (and also unlike ash, upper case PATH doesn't work)

busybox.exe awk "BEGIN{ print ENVIRON[\"Path\"] }"

EDIT2
This conversion was added more than 10 years ago - d5891f9 and it doesn't say why. Later commits added "xp mode" (-X) and unconditional exceptions for COMSPEC and SYSTEMROOT, but I don't think I've seen an explanation of what it's good for in any of them...

[avih]

ping?

[rmyorston]

is there a value in converting backslashes to forward slashes in ENV?

It makes is easier to port Unix scripts and applications to Windows.

If the forward slashes are a problem it's possible to use sh -X. With the latest commit -X no longer needs to be first on the command line.

[avih]

It makes is easier to port Unix scripts and applications to Windows.

It might somewhat, though it's a double-edge sword.

On one hand, I'm guessiung there aren't many portable scripts which use ENV vars other than maybe $TMPDIR and $HOME.

However, it's true that if an existing portable procedure is used on paths with backslashes then things would break.

That being said, if one wants a script to work in busybox-w32, then it's almost inevitable that a path argument would contain backslashes, e.g. when executed from cmd.exe prompt, or a batch file, or windows "Send-To", etc, because scripts which operate exclusively on ENV vars inputs are not very common...

And then there's the issue that some windows program expect the ENV to have backslashes...

Dunno, I think for me I prefer to keep it with backslashes and ensure it's handled correctly equally for ENV vars and elsewhere.

But I get that it can be a subjective thing.

If the forward slashes are a problem it's possible to use sh -X.

Yup. I've mentioned it above too, and I've been using it since.

With the latest commit -X no longer needs to be first on the command line.

Nice. Thanks.

[rmyorston]

It very much depends on circumstances. For what I was doing in 2012 having forward slashes was ideal.

With the latest commit -X no longer needs to be first on the command line.

Nice. Thanks.

And (unlike some others we could mention) the -X option is documented.