How to enter file or folder paths with spaces in Command Prompt on Windows 10

Dec 6, 2019
Comment

We share a lot of tips and tricks that involve running commands in Command Prompt on Windows 10. A lot of common things, such as pinging a server, or checking the status of your network switch are done vie Command Prompt. If you’re not comfortable using the Command Prompt beyond commands that are already written out and to be executed as they are, you tend to miss out on lots of useful things you can do from the Command Prompt. One, rather frequent question that new users have when using the Command Prompt is how to enter the name or address of a folder or file that has a space in its name or in its path.

Generally speaking, if you’re trying to run a command that involves specifying the path to a folder or file, and the path is incorrect i.e., Command Prompt is unable to see it, the error message won’t tell you as much. The message that Command Prompt returns will vary depending on the command you’ve run and it will seem more like there’s something wrong with the command, rather than the path making it more difficult to trouble shoot the problem. The fix is really simple.

Entering paths with spaces

The trick is the double-quotes. Make it a rule of thumb to enclose any and all file paths that you enter in Command Prompt in double quotes.

The following command will not run. The path has a space in it and at that space, the command breaks and Command Prompt thinks you’ve entered a new command or parameter.

This command will work. The only difference between the two is that in the second one, the path is in double-quotes.

Even if your path doesn’t have a space in it, it’s a good idea to enclose it in double-quotes and develop the habit of doing it. If you forget, or you’re dealing with a longer path, a simple error like this might be hard to spot.

This holds true for all command line apps that you use on Windows 10. In PowerShell, any command that requires a file or folder path to be entered should be enclosed in double-quotes. If the path doesn’t have a space in it, you’ll be fine but if it does, the command won’t run so again, this is about developing a habit to save yourself trouble later.

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

How to pass directory path that have space to windows shell?

I am using IEcapt.exe to capture website snapshot. The problem is, it cannot handle path directory that have space. Like this:

Is there any way how I can pass directory like this to make it work?

4 Answers 4

Usually just double-quoting windows paths will work:

If that really doesn’t work, you might be able to get away with using the 8.3 filename or, in the case of program files, the %programfiles% variable.

See the reply from kojiro. However, here is a trick if you really aren’t able to use blank spaces or long file names, because the tools you call do not support that. I’ve had this case with some build tools from MS.

Since short filenames are not allowed to contain blank spaces, we can use:

. where I is the number of the parameter to the current sub (or the script). Since this is a feature that only works on numbered parameters, you may have to use an indirection, such as:

kojiro’s answer works. But in my case I needed to

The second example works with echo command to print the entire path on screen for example, but I needed the first example to pass it correctly to my script.

I wish that I could have used one of the methods above. However, I could only use the old DOS short names.

DOS file names longer than 8 characters were truncated with

number for files. For example, C:\Program Files would be c:\progra

1, and C:\Program Files (x86) would be c:\progra

You can find the short names for files using DIR /X command.

I needed this specifically to launch ConEmu from within Atom text editor.

I derived this approach from Sachleen’s Answer HERE

Spaces and Parenthesis in windows PATH variable screws up batch files

So, my path variable (System->Adv Settings->Env Vars->System->PATH) is set to:

Although, obviously, without the newlines.

Notice the lines containing PathWithSpaces — the first has no spaces, the second has a space, and the third has a space followed by a parenthesis.

Now, notice the output of this batch file:

or specifically the line:

So, what is this bullshit?

• Directory in path that is properly escaped with quotes, but with no spaces = fine
• Directory in path that is properly escaped with quotes, and has spaces but no parenthesis = fine
• Directory in path that is properly escaped with quotes, and has spaces and has a parenthesis = ERROR

Whats going on here? How can I fix this? I’ll probably resort to a junction point to let my tools still work as workaround, but if you have any insight into this, please let me know 🙂

8 Answers 8

This can happen if there are unescaped parentheses in a line inside a «block» (which also uses parentheses for delimiting).

You can usually fix it by turning on delayed expansion and use variables with !var! instead of %var% . There isn’t much more advice I could give without seeing the code.

Note for Windows users on 64-bit systems

1 = ‘Program Files’ Progra

2 = ‘Program Files(x86)’

There should either (a) not be any quotes in the MS-Windows PATH environmental variable (PATH command) or (b) there should be quotes surrounding the entire expression following the (SET command). Unfortunately, this is not very well documented by MS, although they do state that if quotes are used, they will be included in the value of the variable (Windows XP Command Line Reference).

This can cause problems that are inconsistent and therefore difficult to diagnose. For example if your path includes «C:\Python27», your machine will say «‘python’ is not recognized as an internal or external command, operable program or batch file.» when you try to execute python. However some libraries may still be available.

You do not need to «escape» spaces or parentheses. If you need to escape special characters, then put quotes around the entire expression, including the variable name.

or you can use parentheses too.

Note, double quotes must come in pairs.

However, there probably are not any characters that are valid pathnames, that would cause a problem with the SET command.

The solution they suggest is to use delayed expansion.

For setting a path in an if block, rather than using SET PATH= , you should probably use the PATH command.

For other variables, another solution may be to use quotes, but around the whole thing:

Joey in his answer says

This can happen if there are unescaped parentheses in a line inside a «block» (which also uses parentheses for delimiting).

and that’s true. If there are unescaped parentheses one should, well escape them. That’s what I did; I replaced

and this solved the problem.

I’ve experienced something similar. Microsoft explains the issue here: http://support.microsoft.com/kb/329308

Basically, instead of changing the Path variable via System->Adv Settings->Env Vars->System->PATH, try

In Windows 8 I’ve found very little success with any of these methods. Parentheses do not work, quotes work, but the «path» you modify this way isn’t the path that gets used for locating executables, instead cmd still seems to be using the system path it inherited when you opened the window.

example: after determining the processor architecture, I want to add a couple of paths to the PATH environment variable. Actually, even just adding them temporarily would work since I only need them while a batch file is running. But that doesn’t even work.

echo %path% displays the system PATH at the time the cmd was launched.

set path=»%path%;%programfiles(x86)%\company\program\subdir» works but now %path% contains everything surrounded by quotes, and if I try to run a program in subdir from somewhere else, it fails. Using parentheses around the whole thing instead of quotes does not work.

Another thing I’ve noticed is that the same command will work if entered interactively in cmd , but not if encountered in a batch file. That’s frightening. Yet another oddity is the intermittent loss of the last character of an environment variable’s value! Another inconsistency is with third party programs: some can handle a %var% as a parameter, others don’t.

Pass path with spaces as parameter to bat file

I have a simple bat script that copies files from an known directory to a directory given by the user. How can I pass the path (it might contain spaces) to my script and use it with the xcopy command?

In my code i have the following

If I simply call the script I get the following error:

8 Answers 8

Interesting one. I love collecting quotes about quotes handling in cmd/command.

Your particular scripts gets fixed by using %1 instead of «%1» .

By adding an ‘echo on’ ( or getting rid of an echo off ), you could have easily found that out.

1, as stated by @zikaS’ answer. – Diego Queiroz Apr 2 ’18 at 18:01

1 alone removes surrounding quotes. However since you can’t know whether the input parameter %1 has quotes or not, you should ensure by «%

1″ that they are added for sure. This is especially helpful when concatenating variables, e.g. convert.exe «%

1″ in the batch files. But I guess that’s what you meant. – Paul Groke Jun 11 ’12 at 19:12

I think the OP’s problem was that he wants to do BOTH of the following:

• Pass a parameter which may contain spaces
• Test whether the parameter is missing

As several posters have mentioned, to pass a parameter containing spaces, you must surround the actual parameter value with double quotes.

To test whether a parameter is missing, the method I always learned was:

However, if the actual parameter is quoted (as it must be if the value contains spaces), this becomes

which causes the «unexpected» error. If you instead use

then the error no longer occurs for quoted values. But in that case, the test no longer works when the value is missing — it becomes

To fix this, use any other characters (except ones with special meaning to DOS) instead of quotes in the test:

1″ would remove exterior quotations and allow for a real testing, because you never know what the user will type, like this or «this». – Jay Sep 11 ’09 at 12:05

1″ will work most of the time. However there are a few things you need to note for this:

1. It’s not supported in Windows NT 4.0. You need Windows 2000 or later. (If you are coding a script compatible with old OS, beware.)
2. It does not make parameters secure and sanitized. My observation is that there is no way to properly sanitize the command line arguments in CMD scripts.

To demonstrate second point, let me give an example:

Run with example.cmd dummy^&DIR . The ampersand is escaped here ( ^& ) to prevent shell from interpreting as a command delimiter, so that it becomes part of the argument passed to the script. The DIR is interpreted as a command inside the sub-shell running the script, where it shouldn’t.

Quoting it might work some time, but still insecure:

example2.cmd foo^»^&DIR^&^»bar will break it. DIR command will be run two times, one right after SET and the other right after the first ECHO. You see that the «%

1″ you think is quoted well gets unquoted by the argument itself.

So, no way to make parsing arguments secure.

Spaces in windows path breaks in Bash #1766

Comments

themaninthesuitcase commented Mar 9, 2017

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 apm command

The text was updated successfully, but these errors were encountered:

aseering commented Mar 9, 2017

Hi @themaninthesuitcase — just for completeness, could you try running apm.exe (including the .exe )? WSL requires the file extension.

emrsmsrli commented Mar 9, 2017

you can use escape character \ before a space character as in «C:\Users\Emre\ Simsirli» .

aseering commented Mar 10, 2017 •

@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.

aseering commented Mar 10, 2017 •

@emrsmsrli — (a) that’s a Windows path, not a Linux path; and (b) \ is not a Windows path escape character. Your example path represents a folder named Simsirli (note the leading space) inside a folder named Emre .

themaninthesuitcase commented Mar 10, 2017 •

There’s actually apm executable also There isn’t an exe, just apm which is a bash script to detect if it needs to use exe. I did test with .exe but also didn’t work.

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.

themaninthesuitcase commented Mar 10, 2017

Just noticed a bump in window version happened last night: Microsoft Windows [Version 10.0.15048]

emrsmsrli commented Mar 10, 2017

@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
succeeded.

themaninthesuitcase commented Mar 13, 2017

@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.

aseering commented Mar 13, 2017 •

@emrsmsrli — if you manually update $PATH to contain backslashes, does it find your apm binary?

themaninthesuitcase commented Mar 13, 2017

Looks like it «breaks» the path and the issue is more complex than I expected.

Summary of the below:

• Dump the PATH to console
• test the apm command
• update to add \[space] escapes
• test apm command
• which apm to show the path is no longer evaluated fully where it was pre escape or else the issue wouldn’t have been happening.

I am wondering if this issue is not a WSL issue but the app/shell script isn’t managing spaces in the paths internally.

aseering commented Mar 13, 2017

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?

themaninthesuitcase commented Mar 13, 2017

Looking at the errors it seems it’s a propblem internal to this app, I’ll close.

a-nadig commented Oct 27, 2017

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

solesensei commented Oct 24, 2018

Hey, there.
I stucked with same problem.

Path just breaks on first space. Any ideas?

therealkenc commented Oct 24, 2018

KoryNunn commented Nov 15, 2018

Hi, The solution to this is to double-quote the string eg:

solesensei commented Nov 16, 2018

Xdg-open and other applications using unquoted environment variables stay with this problem.

cbdoc commented Dec 7, 2018

This is definitely a bug and should be fixed. To fix manually:

In file /usr/bin/sensible-browser , update line that reads $ «$1» to «$» «$1»

cbdoc commented Dec 7, 2018 •

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:
export BROWSER=»/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe»
export BROWSER=’/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe’
export BROWSER='»/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe»‘
export BROWSER=»/mnt/c/Program\ Files\ (x86)/Google/Chrome/Application/chrome.exe»

All produce the error:
$ source

/.bashrc
$ /usr/bin/sensible-browser
/usr/bin/sensible-browser: 6: /usr/bin/sensible-browser: /mnt/c/Program: not found

The only fix so far: In file /usr/bin/sensible-browser , update line that reads $ «$1» to «$» «$1»

This is definitely a bug and should be fixed.

I assume he means «bug in /usr/bin/sensible-browser «. There is, needless to say, no bug in WSL or Linux. Looks like you could report the bug here. I’d tell you where to to upstream a patch but the upstream Debian git link 404s.

I’m quite familiar with quoting and escape characters in nix

Then you know you can’t fix this with a different $BROWSER shell variable (f.e. in .bashrc ). Because, the $BROWSER variable already contains the correct path if you quote it.

Good point re bug in sensible-browser. Will report there.