I'm running this command on a batch file:
for %I in (*.txt *.doc) do copy %I c:\test2
...and it keeps returning:
I was unexpected at this time.
What is the cause of this error?
If you're running within a batch/cmd file, you need to double the % markers:
for %%i in (*.txt *.doc) do copy %%i c:\test2
The single % variant only works from the command line.
If being run from a batch file, variables need to be denoted with two percent signs, like %%I, only from the command line you use one
I ran across a case where I was getting this error from a file that was named *.cmd. The error arose when I tried to access the first argument to the batch command:
if %1 EQU ""
Once I put quotes around the symbol for the first argument, the warning message went away:
if "%1" EQU ""
Not a direct answer to the question, but if you encounter this message in any program, batch command, etc. then it's most likely related to your PATH containing " characters.
For instance, in Atom editor I was getting the message in the settings view.
"\"GNU was unexpected at this time
This was due to a different program putting in my PATH the following entry
...;C:\"Program Files"\"GNU ARM Embedded;..."
Because of that, the antislash character is read as escaped by some programs, which causes issues because then it's not a pathname delimiter but a simple character.
The solution for me was to remove those " from the PATH, and everything worked fine.
...;C:\Program Files\GNU ARM Embedded;...
PS: I have a doubt whether or not this can impact the original program (GNU ARM Embedded in this case) that maybe does not support spaces in pathnames. If somebody with more insight can clarify in the comments, I will update my post.
Hope this helps
Related
Beginner's question here so I'd be grateful for a baby explanation.
I'm trying to create a concatenation text file that lists the files (with paths) in a certain folder, with the word "file" appended to the beginning of each line, as well as quotation marks. I want the text file to look like this:
file 'file:DriveLetter:\path\filename1.mp3'
file 'file:DriveLetter:\path\filename2.mp3'
etc
The command I'm running is as follows:
(for %i in (*.mp3) do #echo file 'file:%cd%\%i') > mylist.txt
But I receive the following error
%i') was unexpected at this time.
However, if I use double quotes instead of single, the command works. But this causes problems in my next step, which is to use ffmpeg to concatenate the files - it refuses to read the double quote marks.
Any advice is much appreciated. I'm open to an alternative method.
I just tried and everything is working fine. I believe that some character has been altered. Are you sure you're typing your command in your command prompt instead of using some editor (which does automatic modifications) and copying/pasting into a command prompt afterwards?
I ran into an "odd" (to me) problem while writing a batch file, and hope someone can explain why it does what it does... I had a batch file that built-up a moderately complex command-line, and I wanted it to echo what it had built to the screen before executing so that I could check that it had been built correctly. There are other ways I could have done this1, but for various reasons I tried something of the form:
for %%a in (echo "") do %%~a complicated-command-line-with-parameters
The thought being that it would run the do part twice: once with %%a set to echo (displaying the command to the console) and once with it set to "": the expectation was that it would actually execute the command (using %%~a would strip the double-quotes and all that would be left is the command itself). However, while the echo worked, the command itself was not executed.
For a minimal replication, run the following from a command-prompt:
C:\>for %a in (echo "") do %~a dir
C:\>echo dir
dir
C:\> dir
As can be seen, it runs the echo command fine, but it seems that the space in front of dir prevents it from being executed.
Note, though, that manually running a command with a leading space is fine:
C:\> dir
Volume in drive C is OS
Volume Serial Number is A8BD-F861
...
and, were it somehow trying to run the command <space>dir, then it (probably) would have complained of a missing command:
C:\>" dir"
'" dir"' is not recognized as an internal or external command,
operable program or batch file.
Question: The space between %~a (which is an empty string) and the command to be run seems to be causing the whole line to be ignored... does anyone know why?
Note: It make no difference whether it is run from the command-prompt (as above) or from within a .BAT file (after changing %a to %%a etc.). Nor does it make any difference whether the command-to-be-run is a built-in command (e.g. dir as above) or a standalone program.
Further evidence that it is the space between %~a and the command that is causing the problem comes from the "fix" that I found:
C:\>for %a in ("echo " "") do %~adir
C:\>echo dir
dir
C:\>dir
Volume in drive C is OS
Volume Serial Number is A8BD-F861
...
By adding the "separating space" to the "echo " string inside the for command, and removing it from the do clause (...do %~adir), the command works as I originally expected (although I dislike not having a space in front of the command).
After skimming the (somewhat daunting) top answer to the question How does the Windows Command Interpreter (CMD.EXE) parse scripts? that SomethingDark helpfully linked to, a cleaner alternative that seems to work is:
C:\>for %a in (echo call) do %~a dir
C:\>echo dir
dir
C:\>call dir
Volume in drive C is OS
Volume Serial Number is A8BD-F861
...
There are probably idiomatic situations where having the extra call might affect something, but for the moment, it seems to work as desired.
1 I could have put #echo on just before the line inside the batch file, but that also causes the prompt (e.g. C:\MyDirectory\SubDir>) to be shown, which I didn't want. The other "standard fallback" is to just duplicate the line and stick echo in front of the first copy, but then it's too easy for them to get out-of-sync!
SomethingDark already pointed to the explanation.
It's the command vs argument token splitting of a line.
In your case the command token is always %~a this will be replaced later, but even when its empty, the parser will not reevaluate the command token.
With your fix, the dir command is always part of the command token.
But when echo is prefixed it can still echo the remaining part.
Trying to run this particular msiexec command in powershell is becoming an increasing source of frustration for me. When running the below command with the final 'Practice CS' removed, the command works great. As soon as I add 'Practice CS', the MSI help window appears and the command does not install. Also, simply deleting the space and trying with 'PracticeCS' also works. The space itself is killing the msi process. It is inside of quotes so it should work according to all help available.
msiexec /i PracticeCS.msi SHAREDFILESDIR='\\deployment.contoso.local\d$\Applications\Company\WinCSI\Practice CS\'
EDIT 1:
I got it to work with the invocation operator &. I am not sure why the below line works, but it did.
& msiexec /i "\\deployment.contoso.local\d$\Applications\company\wincsi\Practice CS\desktop\MSI\PracticeCS.msi" SHAREDFILESDIR=`"\\deployment.contoso.local\d$\Applications\company\wincsi\Practice CS`"
(imagine only one backtick at the end. cant get punctuation to display correctly)
Take note that the first /i file path works normally with just regular double quotes.
The path SHAREDFILESDIR worked when using the invocation operator combined with the backtick and double quotes ` and ". Using that at beginning and ending got the installer to work.
Anyone know why?
I am looking for a comprehensive list of differences between running the exact same code in the windows cmd windows (entering it manually, line by line) vs. writing a batch file and running that.
I cannot possibly be the fist person to ask this, but neither Google nor multiple stack overflow searches returned what I wanted. I mostly get comparison between .bat & .cmd like this one, or specific questions about a single issue. I know there are other differences, for example i just found out that
set "filename=foo"
set "optional_postfix="
set "filetype=.cpp"
set completename=%filename%%optional_postfix%%filetype%
echo %completename%
PAUSE
behave differently.
I would like to read up on all of the differences since finding out about them after trying something for half an hour that should work and finding out about the difference afterwards is pretty annoying.
If such a list already exists here, please do not downvote me, I actually spent time looking for it and - at least for me - it was not obvious how to find it. Others might have the same issue, so please just mark it as duplicate.
There are numerous differences whether commands are executed in cmd or in batch file context, all of which refer to cmd-internal commands or features though.
The following commands that do nothing when executed in cmd context (they do not produce any output and do not affect ErrorLevel):
goto
shift
setlocal (to en-/disable command extensions or delayed expansion in cmd, invoke the instance using cmd /E:{ON|OFF} /V:{ON|OFF} instead)
endlocal
Labels (like :Label) cannot be used in cmd, they are simply ignored. Therefore call :Label cannot be used too (if you do, an error message appears and ErrorLevel becomes set to 1).
There is of course no argument expansion in cmd since there is no possibility to provide arguments. Hence a string like %1 is just returned as is ( try with echo %1). This allows to define variable names in cmd that begin with a numerical digit, which is not possible in batch files (actually you can define them, but you cannot %-expand them; try this in a batch file: set "123=abc", then set 1; you will get the output 123=abc; but trying to do echo %123% will result in the output 23, because %1 is recognised as argument reference (given that no argument is supplied)).
Undefined environment variables are not expanded (replaced) in cmd but they are maintained literally (do set "VAR=" and echo %VAR%, so you get %VAR%). In batch files however, they are expanded to empty strings instead. Note that in batch files but not in cmd, two consecutive percent signs %% are replaced by a single one %. Also in batch files but not in cmd, a single % sign becomes removed.
More information about the percent expansion (both argument references and environment variables) can be found in this thread: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
The set /A command behaves differently: in cmd it returns the (last) result of an expression on the console (without trailing line-break), but in batch files it does not return anything.
The for command requires its loop variable references to be preceeded by two percent signs (like for %%I in ...) in batch files, but only a single one (like for %I in ...) in cmd. This is a consequence of the different percent expansion handling in batch files and in cmd.
Finally, some commands do not reset the ErrorLevel upon success, unless they are used within a batch file with .cmd extension. These are:
assoc
dpath
ftype
path
prompt
set
More information about resetting the ErrorLevel can be found in this post: Which cmd.exe internal commands clear the ERRORLEVEL to 0 upon success?
This question already has answers here:
How can I echo a newline in a batch file?
(24 answers)
Closed 8 years ago.
When outputting status messages to the console from a Windows batch file, I want to output blank lines to break up the output. How do I do this?
Any of the below three options works for you:
echo[
echo(
echo.
For example:
#echo off
echo There will be a blank line below
echo[
echo Above line is blank
echo(
echo The above line is also blank.
echo.
echo The above line is also blank.
Note: Though my original answer attracted several upvotes, I decided that I could do much better. You can find my original (simplistic and misguided) answer in the edit history.
If Microsoft had the intent of providing a means of outputting a blank line from cmd.exe, Microsoft surely would have documented such a simple operation. It is this omission that motivated me to ask this question.
So, because a means for outputting a blank line from cmd.exe is not documented, arguably one should consider any suggestion for how to accomplish this to be a hack. That means that there is no known method for outputting a blank line from cmd.exe that is guaranteed to work (or work efficiently) in all situations.
With that in mind, here is a discussion of methods that have been recommended for outputting a blank line from cmd.exe. All recommendations are based on variations of the echo command.
echo.
While this will work in many if not most situations, it should be avoided because it is slower than its alternatives and actually can fail (see here, here, and here). Specifically, cmd.exe first searches for a file named echo and tries to start it. If a file named echo happens to exist in the current working directory, echo. will fail with:
'echo.' is not recognized as an internal or external command,
operable program or batch file.
echo:
echo\
At the end of this answer, the author argues that these commands can be slow, for instance if they are executed from a network drive location. A specific reason for the potential slowness is not given. But one can infer that it may have something to do with accessing the file system. (Perhaps because : and \ have special meaning in a Windows file system path?)
However, some may consider these to be safe options since : and \ cannot appear in a file name. For that or another reason, echo: is recommended by SS64.com here.
echo(
echo+
echo,
echo/
echo;
echo=
echo[
echo]
This lengthy discussion includes what I believe to be all of these. Several of these options are recommended in this SO answer as well. Within the cited discussion, this post ends with what appears to be a recommendation for echo( and echo:.
My question at the top of this page does not specify a version of Windows. My experimentation on Windows 10 indicates that all of these produce a blank line, regardless of whether files named echo, echo+, echo,, ..., echo] exist in the current working directory. (Note that my question predates the release of Windows 10. So I concede the possibility that older versions of Windows may behave differently.)
In this answer, #jeb asserts that echo( always works. To me, #jeb's answer implies that other options are less reliable but does not provide any detail as to why that might be. Note that #jeb contributed much valuable content to other references I have cited in this answer.
Conclusion: Do not use echo.. Of the many other options I encountered in the sources I have cited, the support for these two appears most authoritative:
echo(
echo:
But I have not found any strong evidence that the use of either of these will always be trouble-free.
Example Usage:
#echo off
echo Here is the first line.
echo(
echo There is a blank line above this line.
Expected output:
Here is the first line.
There is a blank line above this line.
There is often the tip to use 'echo.'
But that is slow, and it could fail with an error message, as cmd.exe will search first for a file named 'echo' (without extension) and only when the file doesn't exists it outputs an empty line.
You could use echo(. This is approximately 20 times faster, and it works always. The only drawback could be that it looks odd.
More about the different ECHO:/\ variants is at DOS tips: ECHO. FAILS to give text or blank line.