Кавычки в командной строке windows

I think you’ll find that your example works absolutely fine as it is.

cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out"

I have reproduced your example here
http://pastebin.com/raw.php?i=YtwQXTGN

C:\>cmd /c "c:\Program Files\my folder\my long program.exe" > "c:\temp\spaces are here\a.a"

C:\>type "c:\temp\spaces are here\a.a"
my long program.exe has run

C:\>

further example demonstrating it works with "my long program.exe", removing cmd /c, it operates fine too.

C:\>"c:\Program Files\my folder\my long program.exe" > "c:\temp\spaces are here\
a.a"

C:\>type "c:\temp\spaces are here\a.a"
my long program.exe has run

C:\>



Another example, but with replace.  replace with no parameters says "source path required"  "no files replaced"

C:\>replace > a.a
Source path required

C:\>type a.a
No files replaced

Exactly the same effect when they're in folders with spaces.

C:\>cmd /c "c:\Program Files\my folder\replace.exe" > "c:\temp\spaces are here\r.r"
Source path required

C:\>type "c:\temp\spaces are here\r.r"
No files replaced

C:\>

further demonstration with replace
without cmd /c works fine too.

C:\>"c:\Program Files\my folder\replace.exe" > "c:\temp\spaces are here\r.r"
Source path required

C:\>type "c:\temp\spaces are here\r.r"
No files replaced

C:\>

The reason why your example works fine

cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out"

and how/why it works the way it does, is because the > is interpreted as special by the host.exe So this part cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" — I think — is evaluated first. i.e. cmd /c does not see the > and after.

cmd /? shows 2 cases

Case 1 and Case 2. Your example fits Case 1

If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:

    1.  If all of the following conditions are met, then quote characters
        on the command line are preserved:

        - no /S switch
        - exactly two quote characters
        - no special characters between the two quote characters,
          where special is one of: &<>()@^|
        - there are one or more whitespace characters between the
          two quote characters
        - the string between the two quote characters is the name
          of an executable file.

    2.  Otherwise, old behavior is to see if the first character is
        a quote character and if so, strip the leading character and
        remove the last quote character on the command line, preserving
        any text after the last quote character.

You can test for sure that your example fits case 1, because if you add /s (without adding any more quotes or making any change at all to your example other than adding /s), then you get a different result, because it makes your example hit case 2. So that proves that your example is definitely a case 1. And it clearly meets all the criteria of case 1.
If your example were a case 2, and you added /s, then it’d make no difference.

Your answer is interesting because it shows an alternative way of getting your result, but in case 2. By adding additional outter quotes and adding /s.

But actually, when you add those additional outter quotes, then you’ve just made it a case 2, and adding a /s on top of that won’t make a difference.

C:\>cmd /c "c:\Program Files\my folder\replace.exe"
Source path required
No files replaced

C:\>cmd /s /c "c:\Program Files\my folder\replace.exe"
'c:\Program' is not recognized as an internal or external command,
operable program or batch file.

C:\>cmd /c ""c:\Program Files\my folder\replace.exe""
Source path required
No files replaced

C:\>cmd /s /c ""c:\Program Files\my folder\replace.exe""
Source path required
No files replaced

C:\>

The example in your question worked fine

cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out"

Your alternative (with the /S and outer quotes) you give as an answer to make the example work, works fine too

cmd.exe /S /C ""C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out""

Though your answer which is an alternative, can actually be simplified by removing the /S because it’s already a case 2, so adding /s won’t make any difference. So this would improve the solution given in your answer

cmd.exe /C ""C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out""

Your example which you described as a problem in your question, and your solution, produce the same good result. But one big difference I suppose, (and I am not sure how to test for it), but one difference in the way your example works, and the way the solution in your answer works, is I think in the case of your example, the hosting/invoking cmd.exe does the redirect to the file. Whereas in your solution’s example, the invoked cmd.exe is passed the > by the host cmd.exe, and so the invoked cmd.exe does the redirect. Also of course, your example is a case 1, while your solution is an amendment you made (very well) to make it work in case 2.

I hope I haven’t erred here, I may have. But your question and answer did help me wrap my head around how cmd and in particular cmd /c is working!

Perhaps your example was an oversimplification of your actual one, and your actual one did fail and needed your amendment. If your example case, had been a tiny bit more complex, by for example, having a parameter to the program that took quotes, then it’d fail Case 1, and you would indeed need outter quotes (/S would not change the result, so no /S would be necessary, as it’d already be a case 2 once you add those needed outer quotes). But the example you gave in your question actually seems to me to work fine.

Added — A related Q and A What is `cmd /s` for?

Источник

I think you’ll find that your example works absolutely fine as it is.

cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out"

I have reproduced your example here
http://pastebin.com/raw.php?i=YtwQXTGN

C:\>cmd /c "c:\Program Files\my folder\my long program.exe" > "c:\temp\spaces are here\a.a"

C:\>type "c:\temp\spaces are here\a.a"
my long program.exe has run

C:\>

further example demonstrating it works with "my long program.exe", removing cmd /c, it operates fine too.

C:\>"c:\Program Files\my folder\my long program.exe" > "c:\temp\spaces are here\
a.a"

C:\>type "c:\temp\spaces are here\a.a"
my long program.exe has run

C:\>



Another example, but with replace.  replace with no parameters says "source path required"  "no files replaced"

C:\>replace > a.a
Source path required

C:\>type a.a
No files replaced

Exactly the same effect when they're in folders with spaces.

C:\>cmd /c "c:\Program Files\my folder\replace.exe" > "c:\temp\spaces are here\r.r"
Source path required

C:\>type "c:\temp\spaces are here\r.r"
No files replaced

C:\>

further demonstration with replace
without cmd /c works fine too.

C:\>"c:\Program Files\my folder\replace.exe" > "c:\temp\spaces are here\r.r"
Source path required

C:\>type "c:\temp\spaces are here\r.r"
No files replaced

C:\>

The reason why your example works fine

cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out"

cmd /? shows 2 cases

Case 1 and Case 2. Your example fits Case 1

If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:

    1.  If all of the following conditions are met, then quote characters
        on the command line are preserved:

        - no /S switch
        - exactly two quote characters
        - no special characters between the two quote characters,
          where special is one of: &<>()@^|
        - there are one or more whitespace characters between the
          two quote characters
        - the string between the two quote characters is the name
          of an executable file.

    2.  Otherwise, old behavior is to see if the first character is
        a quote character and if so, strip the leading character and
        remove the last quote character on the command line, preserving
        any text after the last quote character.

Your answer is interesting because it shows an alternative way of getting your result, but in case 2. By adding additional outter quotes and adding /s.

But actually, when you add those additional outter quotes, then you’ve just made it a case 2, and adding a /s on top of that won’t make a difference.

C:\>cmd /c "c:\Program Files\my folder\replace.exe"
Source path required
No files replaced

C:\>cmd /s /c "c:\Program Files\my folder\replace.exe"
'c:\Program' is not recognized as an internal or external command,
operable program or batch file.

C:\>cmd /c ""c:\Program Files\my folder\replace.exe""
Source path required
No files replaced

C:\>cmd /s /c ""c:\Program Files\my folder\replace.exe""
Source path required
No files replaced

C:\>

The example in your question worked fine

cmd.exe /C "C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out"

Your alternative (with the /S and outer quotes) you give as an answer to make the example work, works fine too

cmd.exe /S /C ""C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out""

cmd.exe /C ""C:\Program Files\Somewhere\SomeProgram.exe" > "C:\temp\Folder Containing Spaces\SomeProgram.out""

I hope I haven’t erred here, I may have. But your question and answer did help me wrap my head around how cmd and in particular cmd /c is working!

Added — A related Q and A What is `cmd /s` for?

Источник

eplawless’s own answer simply and effectively solves his specific problem: it replaces all " instances in the entire argument list with \", which is how Bash requires double-quotes inside a double-quoted string to be represented.

To generally answer the question of how to escape double-quotes inside a double-quoted string using cmd.exe, the Windows command-line interpreter (whether on the command line — often still mistakenly called the «DOS prompt» — or in a batch file):^{See bottom for a look at PowerShell.}

tl;dr:

The answer depends on which program you’re calling:

You must use "" when passing an argument to a(nother) batch file and you may use "" with applications created with Microsoft‘s C/C++/.NET compilers (which also accept \"), which on Windows includes Python, Node.js, and PowerShell (Core) 7+’s CLI (pwsh) but not Windows PowerShell’s (powershell.exe):
- Example: foo.bat "We had 3"" of rain."
The following applies to targeting batch files only:
- "" is the only way to get the command interpreter (cmd.exe) to treat the whole double-quoted string as a single argument (though that won’t matter if you simply pass all arguments through to another program, with %*)
- Sadly, however, not only are the enclosing double-quotes retained (as usual), but so are the doubled escaped ones, so obtaining the intended string is a two-step process; e.g., assuming that the double-quoted string is passed as the 1st argument, %1:
  - set "str=%~1" removes the enclosing double-quotes; set "str=%str:""="%" then converts the doubled double-quotes to single ones.
    Be sure to use the enclosing double-quotes around the assignment parts to prevent unwanted interpretation of the values.
\" is required — as the only option — by many other programs, (e.g., Ruby, Perl, PHP, as well as programs that use the CommandLineToArgv Windows API function to parse their command-line arguments), but it use from cmd.exe is not robust and safe:
- \" is what many executables and interpreters either require — including Windows PowerShell — when passed strings from the outside, on the command line — or, in the case of Microsoft’s compilers, support as an alternative to "" — ultimately, though, it’s up to the target program to parse the argument list.
  - Example: foo.exe "We had 3\" of rain."
- However, use of \" can break calls and at least hypothetically result in unwanted, arbitrary execution of commands and/or input/output redirections:
  - The following characters present this risk: & | < >
  - For instance, the following results in unintended execution of the ver command; see further below for an explanation and the next bullet point for a workaround:
    - foo.exe "3\" of snow" "& ver."
- For calling the Windows PowerShell CLI, powershell.exe, \"" and "^"" are robust, but limited alternatives (see section «Calling PowerShell’s CLI …» below).
If you must use \" from cmd.exe, there are only 3 safe approaches from cmd.exe, which are, however quite cumbersome: ^{Tip of the hat to T S for his help.}
- Using (possibly selective) delayed variable expansion in your batch file, you can store literal \" in a variable and reference that variable inside a "..." string using !var! syntax — see T S’s helpful answer.
  - The above approach, despite being cumbersome, has the advantage that you can apply it methodically and that it works robustly, with any input.
- Only with LITERAL strings — ones NOT involving VARIABLES — do you get a similarly methodical approach: categorically ^-escape all cmd.exe metacharacters: " & | < > and — if you also want to suppress variable expansion — %:
  foo.exe ^"3\^" of snow^" ^"^& ver.^"
- Otherwise, you must formulate your string based on recognizing which portions of the string cmd.exe considers unquoted due to misinterpreting \" as closing delimiters:
  - in literal portions containing shell metacharacters: ^-escape them; using the example above, it is & that must be ^-escaped:
    foo.exe "3\" of snow" "^& ver."
  - in portions with %...%-style variable references: ensure that cmd.exe considers them part of a "..." string and that that the variable values do not themselves have embedded, unbalanced quotes — which is not even always possible.

Background

^{Note: This is based on my own experiments. Do let me know if I’m wrong.}

POSIX-like shells such as Bash on Unix-like systems tokenize the argument list (string) before passing arguments individually to the target program: among other expansions, they split the argument list into individual words (word splitting) and remove quoting characters from the resulting words (quote removal). The target program is handed an array of individual, verbatim arguments, i.e. with syntactic quotes removed.

By contrast, the Windows command interpreter apparently does not tokenize the argument list and simply passes the single string comprising all arguments — including quoting chars. — to the target program.
However, some preprocessing takes place before the single string is passed to the target program: ^ escape chars. outside of double-quoted strings are removed (they escape the following char.), and variable references (e.g., %USERNAME%) are interpolated first.

Thus, unlike in Unix, it is the target program’s responsibility to parse to parse the arguments string and break it down into individual arguments with quotes removed.
Thus, different programs can require differing escaping methods and there’s no single escaping mechanism that is guaranteed to work with all programs — ^{https://stackoverflow.com/a/4094897/45375 contains excellent background on the anarchy that is Windows command-line parsing.}

In practice, \" is very common, but NOT SAFE from cmd.exe, as mentioned above:

Since cmd.exe itself doesn’t recognize \" as an escaped double-quote, it can misconstrue later tokens on the command line as unquoted and potentially interpret them as commands and/or input/output redirections.
In a nutshell: the problem surfaces, if any of the following characters follow an opening or unbalanced \": & | < >; for example:

foo.exe "3\" of snow" "& ver."

cmd.exe sees the following tokens, resulting from misinterpreting \" as a regular double-quote:

"3\"
of
snow" "
rest: & ver.

Since cmd.exe thinks that & ver. is unquoted, it interprets it as & (the command-sequencing operator), followed by the name of a command to execute (ver. — the . is ignored; ver reports cmd.exe‘s version information).
The overall effect is:

First, foo.exe is invoked with the first 3 tokens only.
Then, command ver is executed.

Even in cases where the accidental command does no harm, your overall command won’t work as designed, given that not all arguments are passed to it.

Many compilers / interpreters recognize ONLY \" — e.g., the GNU C/C++ compiler, Perl, Ruby, PHP, as well as programs that use the CommandLineToArgv Windows API function to parse their command-line arguments — and for them there is no simple solution to this problem.
Essentially, you’d have to know in advance which portions of your command line are misinterpreted as unquoted, and selectively ^-escape all instances of & | < > in those portions.

By contrast, use of "" is SAFE, but is regrettably only supported by Microsoft-compiler-based executables and batch files (in the case of batch files, with the quirks discussed above), which notable excludes PowerShell — see next section.

Calling PowerShell’s CLI from `cmd.exe` or POSIX-like shells:

Note: See the bottom section for how quoting is handled inside PowerShell.

When invoked from the outside — e.g., from cmd.exe, whether from the command line or a batch file:

PowerShell [Core] v6+ now properly recognizes "" (in addition to \"), which is both safe to use and whitespace-preserving.
- pwsh -c " ""a & c"".length " doesn’t break and correctly yields 6
Windows PowerShell (the legacy edition whose latest and final version is 5.1) recognizes only \" or """, the latter being the most robust choice from cmd.exe, in the form "^""" (even though internally PowerShell uses ` as the escape character in double-quoted strings and also accepts "" — see bottom section), as discussed next:

Calling Windows PowerShell from cmd.exe / a batch file:

"" breaks, because it is fundamentally unsupported:
- powershell -c " ""ab c"".length " -> error «The string is missing the terminator»
\" and """ work in principle, but aren’t safe:
- powershell -c " \"ab c\".length " works as intended: it outputs 5 (note the 2 spaces)
- But it isn’t safe, because cmd.exe metacharacters break the command, unless escaped:
  powershell -c " \"a& c\".length " breaks, due to the &, which would have to be escaped as ^&
\"" is safe, but normalizes interior whitespace, which can be undesired:
powershell -c " \""a& c\"".length " outputs 4(!), because the 2 spaces are normalized to 1.
"^"" is the best choice for Windows PowerShell, specifically ^{Credit goes to Venryx for discovering this approach.} and "" for PowerShell (Core) 7+:
- Windows PowerShell: powershell -c " "^""a& c"^"".length " works: doesn’t break — despite & — and outputs 5, i.e., correctly preserved whitespace.
- PowerShell Core: pwsh -c """a& c"".length "
- See this answer for more information.

On Unix-like platforms (Linux, macOS), when calling PowerShell [Core]‘s CLI, pwsh, from a POSIX-like shell such as bash:

You must use \", which, however is both safe and whitespace-preserving:

$ pwsh -c " \"a&  c\".length " # OK: 5

# Alternative, with '...' quoting: no escaping of " needed.
$ pwsh -c ' "a&  c".length ' # OK: 5

Related information

^ can only be used as the escape character in unquoted strings — inside double-quoted strings, ^ is not special and treated as a literal.
- CAVEAT: Use of ^ in parameters passed to the call statement is broken (this applies to both uses of call: invoking another batch file or binary, and calling a subroutine in the same batch file):
  - ^ instances in double-quoted values are inexplicably doubled, altering the value being passed: e.g., if variable %v% contains literal value a^b, call :foo "%v%" assigns "a^^b"(!) to %1 (the first parameter) in subroutine :foo.
  - Unquoted use of ^ with call is broken altogether in that ^ can no longer be used to escape special characters: e.g., call foo.cmd a^&b quietly breaks (instead of passing literal a&b too foo.cmd, as would be the case without call) — foo.cmd is never even invoked(!), at least on Windows 7.
Escaping a literal % is a special case, unfortunately, which requires distinct syntax depending on whether a string is specified on the command line vs. inside a batch file; see https://stackoverflow.com/a/31420292/45375
- The short of it: Inside a batch file, use %%. On the command line, % cannot be escaped, but if you place a ^ at the start, end, or inside a variable name in an unquoted string (e.g., echo %^foo%), you can prevent variable expansion (interpolation); % instances on the command line that are not part of a variable reference are treated as literals (e.g, 100%).
Generally, to safely work with variable values that may contain spaces and special characters:
- Assignment: Enclose both the variable name and the value in a single pair of double-quotes; e.g., set "v=a & b" assigns literal value a & b to variable %v% (by contrast, set v="a & b" would make the double-quotes part of the value). Escape literal % instances as %% (works only in batch files — see above).
- Reference: Double-quote variable references to make sure their value is not interpolated; e.g., echo "%v%" does not subject the value of %v% to interpolation and prints "a & b" (but note that the double-quotes are invariably printed too). By contrast, echo %v% passes literal a to echo, interprets & as the command-sequencing operator, and therefore tries to execute a command named b.
  Also note the above caveat re use of ^ with the call statement.
  - External programs typically take care of removing enclosing double-quotes around parameters, but, as noted, in batch files you have to do it yourself (e.g., %~1 to remove enclosing double-quotes from the 1st parameter) and, sadly, there is no direct way that I know of to get echo to print a variable value faithfully without the enclosing double-quotes.
    - Neil offers a for-based workaround that works as long as the value has no embedded double quotes; e.g.:
      set "var=^&')|;,%!" for /f "delims=" %%v in ("%var%") do echo %%~v
cmd.exe does not recognize single-quotes as string delimiters ('...') — they are treated as literals and cannot generally be used to delimit strings with embedded whitespace; also, it follows that the tokens abutting the single-quotes and any tokens in between are treated as unquoted by cmd.exe and interpreted accordingly.
- However, given that target programs ultimately perform their own argument parsing, some programs such as Ruby do recognize single-quoted strings even on Windows; by contrast, C/C++ executables and Perl do not recognize them.
  Even if supported by the target program, however, it is not advisable to use single-quoted strings, given that their contents are not protected from potentially unwanted interpretation by cmd.exe.

Quoting from within PowerShell:

Windows PowerShell is a much more advanced shell than cmd.exe, and it has been a part of Windows for many years now (and PowerShell Core brought the PowerShell experience to macOS and Linux as well).

PowerShell works consistently internally with respect to quoting:

inside double-quoted strings, use `" or "" to escape double-quotes
inside single-quoted strings, use '' to escape single-quotes

This works on the PowerShell command line and when passing parameters to PowerShell scripts or functions from within PowerShell.

(As discussed above, passing an escaped double-quote to PowerShell from the outside requires \" or, more robustly, \"" — nothing else works).

Sadly, when invoking external programs from PowerShell, you’re faced with the need to both accommodate PowerShell’s own quoting rules and to escape for the target program:

This problematic behavior is also discussed and summarized in this answer; the experimental PSNativeCommandArgumentPassing feature introduced in PowerShell Core 7.2.0-preview.5 — assuming it becomes an official feature — will fix this at least for those external programs that accept \".

Double-quotes inside double-quoted strings:

Consider string "3`" of rain", which PowerShell-internally translates to literal 3" of rain.

If you want to pass this string to an external program, you have to apply the target program’s escaping in addition to PowerShell’s; say you want to pass the string to a C program, which expects embedded double-quotes to be escaped as \":

foo.exe "3\`" of rain"

Note how both `" — to make PowerShell happy — and the \ — to make the target program happy — must be present.

The same logic applies to invoking a batch file, where "" must be used:

foo.bat "3`"`" of rain"

By contrast, embedding single-quotes in a double-quoted string requires no escaping at all.

Single-quotes inside single-quoted strings do not require extra escaping; consider '2'' of snow', which is PowerShell’ representation of 2' of snow.

foo.exe '2'' of snow'
foo.bat '2'' of snow'

PowerShell translates single-quoted strings to double-quoted ones before passing them to the target program.

However, double-quotes inside single-quoted strings, which do not need escaping for PowerShell, do still need to be escaped for the target program:

foo.exe '3\" of rain'
foo.bat '3"" of rain'

PowerShell v3 introduced the magic --% option, called the stop-parsing symbol, which alleviates some of the pain, by passing anything after it uninterpreted to the target program, save for cmd.exe-style environment-variable references (e.g., %USERNAME%), which are expanded; e.g.:

foo.exe --% "3\" of rain" -u %USERNAME%

Note how escaping the embedded " as \" for the target program only (and not also for PowerShell as \`") is sufficient.

However, this approach:

does not allow for escaping % characters in order to avoid environment-variable expansions.
precludes direct use of PowerShell variables and expressions; instead, the command line must be built in a string variable in a first step, and then invoked with Invoke-Expression in a second.

An alternative workaround* that addresses this problem is to call via cmd /c with a single argument containing the entire command line:

cmd /c "foo.exe `"3\`" of rain`" -u $env:USERNAME"

Thus, despite its many advancements, PowerShell has not made escaping easier when calling external programs — on the contrary. It has, however, introduced support for single-quoted strings.

If you don’t mind installing a third-party module (authored by me), the Native module (Install-Module Native) offers backward- and forward-compatible helper function ie, which obviates the need for the extra escaping and contains important accommodations for high-profile CLIs on Windows:

# Simply prepend 'ie' to your external-program calls.
ie foo.exe '3" of rain' -u $env:USERNAME

Источник

Кавычки в командной строке Windows используются для указания, что их содержимое является единым целым. Они могут использоваться для передачи параметров, имеющих пробелы или специальные символы, а также для указания параметров, содержащих другие параметры.

Одинарные и двойные кавычки

Кавычки в командной строке могут быть одинарными или двойными. Одинарные кавычки (‘) обычно используются в командной строке для отображения специальных символов без их интерпретации. Например, если вы хотите передать имя файла, содержащее пробел, то можете заключить его в одинарные кавычки.

Двойные кавычки («) используются для определения строки параметров. Когда в строке параметров есть пробелы, необходимо заключить ее в двойные кавычки, чтобы она отображалась как единое целое.

Использование кавычек в переменных окружения

В переменные окружения также можно заключить в кавычки. Например, если вы хотите установить переменную окружения с именем NEW_DIR, которая содержит пробелы, то необходимо заключить ее значение в кавычки. Вы можете сделать это следующим образом: set NEW_DIR="C:\New Directory"

Передача параметров в командную строку

Чтобы передать параметры, содержащие пробелы или ограниченные другими специальными символами, нужно заключить их в кавычки. Например, чтобы скопировать файл с именем «my file.txt» в папку «c:\myfolder», необходимо выполнить следующую команду: copy "my file.txt" "c:\myfolder\"

Использование символов кавычек в качестве части параметра

Если вы хотите использовать символы кавычек в качестве части параметра, то необходимо их экранировать обратным слешем (). Например, если вы хотите передать строку «hello «world»», то синтаксис будет следующим: echo \"hello \"world\"\"

Ошибки, связанные с использованием кавычек

Некоторые ошибки, связанные с использованием кавычек, могут возникнуть в случае неправильного использования. Например, если строка команды содержит только одну двойную кавычку, командная строка не выполнится. Также возможны проблемы, связанные с неправильным экранированием кавычек, которые могут привести к непредвиденным результатам или ошибкам.

Заключение

Кавычки в командной строке Windows используются для передачи параметров, содержащих пробелы или специальные символы, а также для указания параметров, содержащих другие параметры. Одинарные и двойные кавычки могут использоваться в зависимости от конкретной задачи. Если вы используете кавычки, следует убедиться, что они используются правильно, чтобы избежать ошибок.

Источник

В пакетном файле Windows, когда вы делаете следующее:

set myvar="c:\my music & videos"

переменная myvar сохраняется с включенными кавычками. Честно говоря, я нахожу это очень глупым. Кавычки — это просто указать, где начинается и заканчивается строка, а не сохраняться как часть самого значения.
Как я могу предотвратить это?

Спасибо.

Ответ 1

set "myvar=c:\my music & videos"

Обратите внимание на начало цитат перед myvar. Это на самом деле так просто.
Боковое примечание: myvar не может быть отозван после этого, если он не заключен в кавычки, потому что и будет считан как разделитель команд, но он все равно будет работать как путь.

http://ss64.com/nt/set.html в разделе «Имена переменных могут включать пробелы»

Ответ 2

Это правильный способ сделать это:

set "myvar=c:\my music & videos"

Кавычки не будут включены в значение переменной.

Ответ 3

Это зависит от того, как вы хотите использовать переменную. Если вы просто хотите использовать значение переменной без кавычек, вы можете использовать замедленное расширение и замену строки или команду for:

@echo OFF
SETLOCAL enabledelayedexpansion

set myvar="C:\my music & videos"

В качестве состояний andynormancx необходимы кавычки, поскольку строка содержит &. Или вы можете избежать его с помощью ^, но я думаю, что цитаты немного чище.

Если вы используете замедленное расширение с заменой строки, вы получаете значение переменной без кавычек:

@echo !myvar:"=!
>>> C:\my music & videos

Вы также можете использовать команду for:

for /f "tokens=* delims=" %%P in (%myvar%) do (
    @echo %%P
)
>>> C:\my music & videos

Однако, если вы хотите использовать переменную в команде, вы должны использовать указанное значение или заключить значение переменной в кавычки:

Использование замены строк и замедленного расширения для использования значения переменной без кавычек, но используйте переменную в команде:
```
@echo OFF
SETLOCAL enabledelayedexpansion

set myvar="C:\my music & videos"
md %myvar%
@echo !myvar:"=! created.
```
Использование команды for для использования значения переменной без кавычек, но вам придется окружать переменную кавычками при ее использовании в командах:
```
@echo OFF
set myvar="C:\my music & videos"

for /f "tokens=* delims=" %%P in (%myvar%) do (
    md "%%P"
    @echo %%P created.
)
```

Короче говоря, на самом деле нет чистого способа использовать путь или имя файла, содержащее встроенные пространства и/или & в пакетном файле.

Ответ 4

Использовать jscript.

Многие луны назад (т.е. около 8 лет дают или берут) Я работал над большим проектом С++/VB6, и у меня было несколько бит Batch Script, чтобы сделать части сборки.

Затем кто-то указал мне на Joel Test, я был особенно влюблен в пункт 2 и решил принести все мои маленькие скрипты сборки в один single build Script.,.

и это почти сломало мое сердце, заставив все эти маленькие скрипты работать вместе, на разных машинах, с немного разными настройками, боги, это было ужасно — в частности, установление переменных и передача параметров. Это было действительно хрупкое, малейшее дело сломало бы его и потребовало бы 30 минут настройки, чтобы снова идти.

В конце концов — я могу быть упрямым — Я забросил всю игру и за день переписал все это в JavaScript, запустив его из командной строки с CScript.

Я не оглядывался назад. Хотя в наши дни это MSBuild и Cruise Control, если мне нужно что-то даже немного задействовать с пакетом script, я использую jscript.

Ответ 5

Командный интерпретатор Windows позволяет использовать кавычки вокруг всей команды набора (действителен в каждой версии Windows NT от NT 4.0 до Windows 2012 R2)

Ваш script должен быть написан следующим образом:

@echo OFF

set "myvar=C:\my music & videos"

Затем вы можете поместить кавычки вокруг переменных по мере необходимости.

Работа с приглашением CMD может казаться эзотерическим время от времени, но интерпретатор команд действительно ведет себя довольно твердо, подчиняясь его внутренней логике, вам просто нужно переосмыслить вещи.

Фактически команда set не требует, чтобы вы использовали кавычки вообще, но как то, как вы выполняете назначение переменной, так и способ использования кавычек не может вызвать лишние пробелы вокруг вашей переменной, когда вы отлаживаете script.

например. Оба нижеследующих являются технически допустимыми, но вы можете иметь конечные пробелы, поэтому это не очень хорошая практика:

set myvar=some text   
set myvar="some text"

например. Оба из этих правил являются хорошими методами для установки переменных в интерпретаторе команд Windows, однако метод двойной кавычки превосходит:

set "myvar=Some text"
(set myvar=Some value)

Оба они не оставляют ничего для интерпретации, переменная будет иметь точно данные, которые вы ищете.

сильный текст Однако для ваших целей только цитируемый метод будет работать корректно, потому что вы используете зарезервированный символ

Таким образом, вы должны использовать:

set myvar="c:\my music & videos"

Однако, несмотря на то, что переменная IS правильно настроена на эту строку, когда вы ECHO на sting, интерпретатор команд интерпретирует амперсанд, поскольку ключевое слово указывает, что следующий оператор следует.

SO, если вы хотите повторить строку из переменной, интерпретатору CMD все равно нужно сообщить ему текстовую строку или если вы не хотите, чтобы кавычки отображались, вам нужно выполнить одно из следующих действий:

эхо переменная WITH Quotes:

Echo."%myvar%"

эхо переменная WITHOUT Quotes:

Echo.%myvar:&=^&%
<nul SET /P="%myvar%"

В приведенных выше двух сценариях вы можете повторять строку без каких-либо кавычек. Пример ниже:

C:\Admin>    Echo.%myvar:&=^&%
C:\my music & videos

C:\Admin>    <nul SET /P="%myvar%"
C:\my music & videos
C:\Admin>

Ответ 6

У вас должны быть кавычки, если текст, который вы устанавливаете, включает определенные символы, включая &. Если ваш текст не включал &, вам не нужны кавычки.

Например, если текст был просто «c:\my music», вы могли бы сделать:

set myvar = c:\my music

Но поскольку у вашего текста есть &, вам нужны кавычки.

Edit:

Или, как говорит Дэйв в своем ответе, вы можете избежать проблемных символов с помощью ^^^, но остерегайтесь этого подхода, поскольку & не единственный персонаж, которого вы нужно бежать. На практике гораздо проще придерживаться кавычек, а не избегать всех проблемных символов.

Ответ 7

Попробуйте использовать escape-символ ‘^’, например

set myvar=c:\my music ^& videos

Вы будете осторожны при расширении myvar, потому что оболочка может не обрабатывать и как литерал. Если вышеописанное не работает, попробуйте также вставить каретку в строку:

set myvar=c:\my music ^^^& videos

Источник

Background

Calling PowerShell’s CLI from cmd.exe or POSIX-like shells:

Related information

Quoting from within PowerShell:

Одинарные и двойные кавычки

Использование кавычек в переменных окружения

Передача параметров в командную строку

Использование символов кавычек в качестве части параметра

Ошибки, связанные с использованием кавычек

Заключение

Ответ 1

Ответ 2

Ответ 3

Ответ 4

Ответ 5

Ответ 6

Ответ 7

Calling PowerShell’s CLI from `cmd.exe` or POSIX-like shells: