Spaces in windows path breaks in Bash #1766
Comments
|
Hi @themaninthesuitcase -- just for completeness, could you try running |
|
you can use escape character |
|
@themaninthesuitcase -- I have verified that WSL is behaving correctly. The problem here is that you forgot to type the ".exe" on the end of the command name. Spaces do not need to be escaped in Linux $PATH. |
|
@emrsmsrli -- (a) that's a Windows path, not a Linux path; and (b) |
|
My current theory seems to be paths in the Windows path section with spaces do not work and would need to be escaped when combined with the Ubuntu path. |
|
Just noticed a bump in window version happened last night: Microsoft Windows [Version 10.0.15048] |
|
@aseering it at least is a workaround for changing directories which contain spaces. please see the image below, there first command gives the error directory does not exist but the second one
|
|
@emrsmsrli this isn't all that useful when it's the automatically generated path (Ubuntu + Windows) that has the spaces. I don't plan on typing /mnt/c/some\ long\ path\app.exe every time I want to run something that's already in the path. My envisioned fix is that the auto combine process is updated to escape spaces exactly like that though. It's not just "User Name" paths that will see this issue but also anything in Program Files. |
|
@emrsmsrli -- if you manually update $PATH to contain backslashes, does it find your |
|
Looks like it "breaks" the path and the issue is more complex than I expected. Summary of the below:
I am wondering if this issue is not a WSL issue but the app/shell script isn't managing spaces in the paths internally. |
|
Again, @themaninthesuitcase , my machine has no problems finding binaries in paths containing spaces. $PATH does not need spaces to be escaped on my machine. In fact, escaping spaces in $PATH breaks it on my machine. The default bash shell has no problem handling paths with spaces; it correctly quotes them internally. Is it possible that the problem isn't with the $PATH variable but with some other piece of your environment? |
|
Looking at the errors it seems it's a propblem internal to this app, I'll close. |
|
I have a similar issue with automatic handling of spaces. I tried creating a python virtual environment in bash on windows but I can't pip install anything because the parent folder has a space in it PS. I wasn't sure if i should comment on closed issues. Do let me know if im doing the wrong thing here |
|
Hey, there. SoleSensei@SoleSurface:~$ $BROWSER
-bash: /mnt/c/Program: No such file or directory
SoleSensei@SoleSurface:~$ export BROWSER='"/mnt/c/Program\ Files/Firefox/firefox.exe"'
SoleSensei@SoleSurface:~$ $BROWSER
-bash: "/mnt/c/Program\: No such file or directory
SoleSensei@SoleSurface:~$ export BROWSER="/mnt/c/Program\ Files/Firefox/firefox.exe"
SoleSensei@SoleSurface:~$ $BROWSER
-bash: /mnt/c/Program\: No such file or directory
SoleSensei@SoleSurface:~$ export BROWSER=/mnt/c/Program\ Files/Firefox/firefox.exe
SoleSensei@SoleSurface:~$ $BROWSER
-bash: /mnt/c/Program: No such file or directory
SoleSensei@SoleSurface:~$ export BROWSER='/mnt/c/Program Files/Firefox/firefox.exe'
SoleSensei@SoleSurface:~$ $BROWSER
-bash: /mnt/c/Program: No such file or directory
SoleSensei@SoleSurface:~$ xdg-open https://github.com
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: /mnt/c/Program: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: /mnt/c/Program: not found
xdg-open: no method available for opening 'https://github.com'Path just breaks on first space. Any ideas? |
|
|
Hi, The solution to this is to double-quote the string eg: Found here: https://stackoverflow.com/questions/40135502/opening-sublime-text-from-bash-on-ubuntu-on-windows |
|
@therealkenc, @KoryNunn thanks, guys Xdg-open and other applications using unquoted environment variables stay with this problem. |
|
This is definitely a bug and should be fixed. To fix manually: In file |
|
This is not a bug. In any 'nix or Windows & Windows WSL it is necessary to
escape space. Quoting is the most convenient way though the back slash can
work just as well. Such as /mnt/c/Program\ Files/java or "/mnt/c/Program
Files/java" also learn the difference between strong quotes 'like this' and
standard quotes "like this". Strong quotes will not allow the expansion of
env variables standard will.
…On Thu, Dec 6, 2018 at 7:48 PM cbdoc ***@***.***> wrote:
This is definitely a bug and should be fixed. To fix manually:
In file /usr/bin/sensible-browser, update line that reads ${BROWSER} "$1"
to "${BROWSER}" "$1"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1766 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGW9mFeAq5vY0aUUNMvh6-u2uZs3Zkszks5u2brcgaJpZM4MX_ss>
.
|
|
I'm quite familiar with quoting and escape characters in nix. It simply does not work when passing the $BROWSER variable from bash to sensible-browser. In .bashrc, I tried single quote, double quotes, escape characters and even double quote embedded in single quote: All produce the error: The only fix so far: In file
Good point re bug in sensible-browser. Will report there. |
I assume he means "bug in
Then you know you can't fix this with a different |
|
Or use a wrapper script, and put it in your PATH. (ie #!/usr/bin/env bash
# -*- coding: utf-8 -*-
# Filename: chrome
# Description: chrome.exe wrapper for $BROWSER
# "unofficial" bash strict mode. See: http://redsymbol.net/articles/unofficial-bash-strict-mode
set -o errexit # Exit when simple command fails 'set -e'
#set -o errtrace # Exit on error inside any functions or subshells.
set -o nounset # Trigger error when expanding unset variables 'set -u'
set -o pipefail # Do not hide errors within pipes 'set -o pipefail'
IFS=$'\n\t'
declare -gx CHROME
CHROME="/c/Program Files (x86)/Google/Chrome/Application/chrome.exe"
find_browser_env() {
if [[ -z "${BROWSER-}" ]]; then
printf 'Cannot find BROWSER environment variable. Add this to your ~/.bashrc:\n\n' >&2
printf '\tdeclare -g BROWSER\n' >&2
printf '\tBROWSER=%s\n' "${BASH_SOURCE[0]}" >&2
# shellcheck disable=SC2016
printf '\tif [[ -x "${BROWSER}" ]]; then\n' >&2
printf '\t export BROWSER\n' >&2
printf '\telse\n' >&2
printf '\t unset -v BROWSER\n' >&2
printf '\tfi\n' >&2
fi
}
"${CHROME}" "$@"
find_browser_envThe bare essentials version: #!/usr/bin/env bash
CHROME="/c/Program Files (x86)/Google/Chrome/Application/chrome.exe"
"${CHROME}" "$@" |
|
I have the error of $PATH got cut off after the first space when I installed yvm When installing a fresh Ubuntu, echo $PATH show up correctly, after install yvm the problem appeared |
|
In case you need to run incognito mode from your WSL |
|
I don't know why anyone here faults this to the user. In Windows paths don't need to be escaped, that's why no program out there escapes their path they add.
Notice how everything after "Program Files" is cut off? How is it not WSL's bug when it automatically adds Windows paths which work on Windows like they are, to the bash in a way that breaks them? What is the user supposed to do, modify all their Windows paths? And do it again any time some program adds their path? |
That is linux-behavior. You've attempted to execute a long string with colons and forward slashes in it. The long string before the space is not a directory in your Linux filesystem, hence the error.
They do, because in the example below,
Opening a discussion with your use case and and detailed repro steps is one approach. Superuser (and similar) is another, because there are more eyeballs and the behavior is not specific to WSL. |
|
I fixed the error, by not adding the Windows Path entries to the Linux Path. Add the following content: Save the file and restart the wsl. Start a new wsl termial and check if the Windows Path entries are gone Output should look like |
|
my $PATH is now showing correctly, maybe an update fixed it |
|
I had great difficulty getting the escaped strings correct when appending a path so I just used the 8.3 file names (dir /x), e.g. |
As an WSL user, I was getting `env: 'Files': Permission denied` error for each `make` command I ran in few different FT repos. I looked up into n-gage source and I was able to locate the reason. It is not caused by n-gage or make, but by having Windows paths with spaces added to Linux path. Got this solution microsoft/WSL#1766 (comment) after googling and described the problem and the workaround into this PR. I have applied on my system and it solved the problem. Suggesting to add it to the README.
|
I'm having the same issue. The PATH that WSL2 imports from Windows is broken, as it is not escaping characters properly. Restarting WSL2 does not fix. I am not adding anything to the path, and .bashrc is vanilla. This is the path that WSL2 creates on boot. $PATH outputs: This broken path causes issues when installing nvm, as nvm, as per the official documentation from Microsoft for installing nvm/node tells you to run the shell script to install, which appends to the path, which does not work since there is a broken path in the middle. This appears to be a bug in /etc/wsl.conf line 6, I can't seem to edit this file, but I wrote a workaround to escape all paths that have spaces. This can be added to ~/.profile to fix this issue, but shouldn't this really be fixed by Windows? `# fix for Windows Subsystem for Linux not escaping imported paths with quotes (escapes ALL paths with quotes) since can't edit /etc/wsl.conf directly to fix line 6 which imports the snap_bin_path from windows:Can't use sed since it doesn't have lazy match, so just use a string split function:IN=$PATH There's a thread on Stack overflow about this here: |
|
As much discussion of "This is a user problem" as there is this does break scripts that are not perfectly written. Many scripts that would/should work on a real Linux box fail here because there are no spaces by default in the Linux path. In the Windows path however there are spaces and they are not escaped before passed in to wsl. This can be fixed by better scripts from the maintainer of the softwares however if they are not specifically supporting wsl they usually see no need. It does seem like something that is not hard to fix when appending the windows path to wsl. There are a lot of factors but the easiest solution seems to me to be at the root of the problem, a path with spaces being appended to the default Linux path. I bet that script from @humandevs could be integrated into wsl to make life easier for people instead of people having to find random ideas and solutions. :) |
Brief description
Using windows tools from Bash fails when using a path that has a space.
The windows path is added to the $PATH and some translation happens ie C: => /mnt/c. Spaces are not managed in this translation. This means any windows path that includes a space (Program Files or user paths with a space as below) fail to find files.
Expected results
Files found and are accessible.
Actual results
Windows build number
Microsoft Windows [Version 10.0.15042]
Repro Steps
Install Atom Editor & node.js in windows land
open bash shell
run
apmcommandThe text was updated successfully, but these errors were encountered: