2

A similar question has been asked with no satisfying answer. I installed kaldi on WSL and when running a script I get this error, that apparantely has to do with "Program Files".

sh: 1: export: Files/WindowsApps/CanonicalGroupLimited.UbuntuonWindows_2004.2021.222.0_x64__79rhkp1fndgsc:/mnt/c/ProgramData/Oracle/Java/javapath:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program: bad variable name

One of the answers was to make a link "Program" to "Program Files". But, it fails: /mnt/c$ sudo ln -s /mnt/c/"Program Files" Program ln: failed to create symbolic link 'Program' Making the link on the windows side succeeds but has no effect.

user535733
  • 62,253
Adoram
  • 31
  • 1
  • 2
  • 1
    Does this answer your question? Why I obtain this error when I try to perform this simple bash script? – user535733 Jul 30 '21 at 14:01
  • @user535733 This does not look like a duplicate of that question at all – NotTheDr01ds Jul 30 '21 at 15:21
  • @NotTheDr01ds you sure? Aside from the actual path used, this error is pretty much duplicated there. – muru Jul 30 '21 at 17:16
  • @muru I've seriously thought about changing my profile to read "I've been using Linux 4 times longer than muru, but muru knows 4 times more than I do about it." (i.e. Muru, you rock!). But I'm fairly sure in this case that the linked question is similar in error only. That one was caused by an obviously bad use of the export command. I could be wrong, but I'm pretty dang certain this is a variable quoting issue that is causing the export to fail. I'm sure we can find another question that might be a better "duplicate" candidate, but the WSL aspects also make this one a bit more "special". – NotTheDr01ds Jul 30 '21 at 17:26
  • Seems to really be an almost exact duplicate of this one, but there's really no good answer on that one either. Since that OP abandoned WSL for "pure" Ubuntu, I don't see them ever accepting an answer (they pretty much said so in a comment). For that reason, I'd propose that we close the earlier question in favor of this one (or find another duplicate). It's not usual, but I've seen instances across Stack sites where it was done for reasons like this. – NotTheDr01ds Jul 30 '21 at 17:42
  • Please [edit] and provide the link to the 'similar question' to you refer to in your question – Greenonline Aug 09 '21 at 02:07

3 Answers3

1

I have a hunch that this is caused by something in your script or startup files (assuming ~/.bashrc or ~/.profile) not properly quoting the PATH variable. Because WSL appends the Windows path to the WSL path automatically, it's adding some path elements with "Program Files" in, which is correct.

But it does require proper variable quoting. Check your script for use of $PATH and quote it (or add the potentially offending lines to your question if you need help with that). If you don't see anything suspect in the script, then also check your ~/.bashrc and ~/.profile.

Edit/update: I'm fairly sure the offending line will be in the script which is being processed through dash (i.e. sh). Bash can handle this just fine without additional quoting:

> export PATH=$PATH:newpath
> echo $?
0
> echo $PATH
> # outputs correct PATH, even with spaces in the Windows path

However, run sh and try the same:

$ export PATH=$PATH:newpath
sh: 1: export: Files/NVIDIA: bad variable name
$ export PATH="$PATH":newpath
$ echo $?
0
$ echo $PATH
# outputs correct PATH, even with spaces in the Windows path

There's also a "bandaid" solution to disable the WSL feature that appends the Windows path to the WSL/Linux path. You can do this by creating (or editing if it already exists) /etc/wsl.conf and adding the following lines:

[interop]
appendWindowsPath=false

Then stop the instance with wsl --terminate Ubuntu (assuming the default distro name), and restart WSL.

It's not a good permanent solution, IMHO, since it makes it far more difficult to run Windows apps (such as VSCode) when they aren't in the path.

Better to figure out the core issue and fix it in the scripts.

NotTheDr01ds
  • 17,888
  • @steeldriver I was thinking that, but then I figured the mangled PATH might still occur in ~/.bashrc and then, since it's exported, would be picked up by the script in question (which is likely running under a sh shebang). That said, the more I think about it, the more I believe the quoting problem probably lies within the script in question. – NotTheDr01ds Jul 30 '21 at 17:09
  • @steeldriver Yes, I do mention that Windows appends the Windows path in the question, but there's also some prepending going on for some reason -- /mnt/c/Program Files/WindowsApps/CanonicalGroupLimited.UbuntuonWindows_2004.2021.222.0_x64__79rhkp1fndgsc is getting prepended, and that's unusual in WSL. You are right that it shouldn't be WSL that is doing this part. – NotTheDr01ds Jul 30 '21 at 17:32
  • @steeldriver I see the confusion - My statement was a bit ambiguous. When I said "prepending the Windows path to the actual Ubuntu UWP app", I meant that app path (not the "Windows path"). Edited to try to remove some of the ambiguity. – NotTheDr01ds Jul 30 '21 at 17:35
  • @steeldriver Oops - I was thinking that the first path was prepended, but now I see that the entire error is part of the appended path (including the UWP path). I'll edit my answer to remove that part. Thanks! – NotTheDr01ds Jul 30 '21 at 17:57
  • Yeah it's getting tokenized as export PATH=everything-up-to-first-whitespace everything-up-to-next-whitespace which is equivalent to export PATH=everything-up-to-first-whitespace followed by export everything-up-to-next-whitespace. Another solution is simply to make sure $PATH is quoted on the RHS of the assignment. – steeldriver Jul 30 '21 at 18:01
  • @steeldriver "Another solution is simply to make sure $PATH is quoted on the RHS of the assignment." That's exactly the solution, I believe. Just have to find the offending line and fix it, which will be up to the OP to do. – NotTheDr01ds Jul 30 '21 at 18:02
  • 1
    BTW your observation about sh versus bash is spot on - see When is double-quoting necessary?, in particular the section about the RHS of an assignment in Where you can omit the double quotes Note that you do need the double quotes after export, because it's an ordinary builtin, not a keyword. This is only true in some shells such as dash, zsh (in sh emulation), yash or posh; bash and ksh both treat export specially. – steeldriver Jul 30 '21 at 20:49
0

I found the answer in https://arstechnica.com/civis/viewtopic.php?f=16&t=1472885 You need to remove the windows paths from $PATH, and you do that by creating /etc/wsl.conf with the following text: [interop] appendWindowsPath=False Then close the WSL window, wait 8 sec, and relauch.

Adoram
  • 31
  • 1
  • 2
  • Yes, I mentioned that being part of the problem in the first paragraph of my answer yesterday, and gave the wsl.conf option as a workaround, so you should accept that answer. Also note that removing the Windows path from WSL will reduce its functionality and usefulness, so it's recommended that you correct the quoting error in the script instead. – NotTheDr01ds Jul 31 '21 at 16:11
0

I may be a little late to the game here, but posting this in case anyone else stumbles across this thread. I was having this same issue with a fresh install of WSL using Ubuntu, and it was fixed by simply running these commands (as root) in WSL:

$ sudo apt update && sudo apt upgrade -y

All I had to do was restart my WSL terminal after this and the issue disappeared. Hope this helps someone!

th317erd
  • 131