I have always used start /w in batch files and from a Windows console to run something and pause till the application is closed. But since a few weeks ago, this does not work anymore!
I tried to simply open one by one the .pdf files in a folder and it doesn't work. So I studied for at least 3 hours what could be wrong to no avail. And nobody on the Internet seems to mention a problem like that. Today I picked a batch I used in the past to open files in sequence and it doesn't work anymore either. It would use two simple batches, the core one doing just this:
cd %1
for %%f in (*.py) do start /wait %%f
cd ..
I am pretty sure I used it successfully on the same machine I use now (Win7 Professional, 64-bit). I tried all sorts of things like call, command /b with the command, but none of them works.
From the console when I do ver I get Microsoft Windows [Version 6.1.7601] (from the 32 or the 64-bit console).
What do you think has gone wrong here?
In one of your comments, you show that the following specific command fails from the command line:
for %a in (*.pdf) do start /wait "C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.exe" %a
It doesn't work properly because the first argument is treated as a title if it is quoted. If you need to quote your executable, then you must precede the program with a quoted title. You can provide an empty title if you want:
for %a in (*.pdf) do start /wait "" "C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.exe" %a
Related
A standard implementation of this technique is provided at: https://learn.microsoft.com/en-us/troubleshoot/windows-client/printing/add-print-directory-feature
Unfortunately it does not work for me. The Printdir.bat file is:
#echo off
dir %1 /-p /o:gn > "%temp%\Listing"
start /w notepad /p "%temp%\Listing"
del "%temp%\Listing"
exit
My implementation fails at the cmd level with the error:
The filename, directory name, or volume label syntax is incorrect".
(The program continues and results in no file created since nothing is passed to notepad).
If run in the Windows directory, it runs fine.
Adding quotes around "%1" did not help and neither did "%~1"
The instructions (repeated at several sites) created a file PrintDirectoryListing.reg with steps 3 and 6 creating a command Printdir.bat \"%1\"
From the comments by aschipfl and Mofi, I was able to troubleshoot the activity and edit the registry, eliminate the \ before "%1" making both commands Printdir.bat "%1\".
Now everything works properly. Thanks again to aschipfl and Mofi
I have a batch script that needs to run as admin. I will be distributing to users so it would be best if they can run it from Windows Explorer.
Unfortunately, it doesn't work when run from explorer (right click -> run as admin). It does work when called from a pre-existing admin terminal.
Initially I thought the problem was with the active directory, but I added a "cd /d %~dp0" as the first command. I confirmed through echo that this places them both in the same directory, but it still fails when running from explorer.
The failure occurs when reading an external file in the same directory as the .bat. It pulls empty strings when run from explorer. Here is sample code:
rem Make sure active directory is correct (verified that this works)
cd /d %~dp0
rem Load parameters from params.txt
for /f "delims== tokens=1,2" %%G in ("params.txt") do set %%G=%%H
rem Print params (it's a loop so you can read it when running from expl.)
for /l %%a in (1 1 100000) do echo %DST%
Then you just need to make sure params.txt is in same directory as .bat and includes the line "DST=some\directory\name"
Anybody know why this doesn't work?
As has been pointed about by #nephi12 in his answer if your file name does not have spaces you can remove the quotes, otherwise it thinks the IN clause is a string you want to parse. If you need to quote your file names then you need to use the USEBACKQ option as pointed out by the comments. Once you use that option your code works just fine.
But I would like to make a point with your code. If the contents of your params.txt file is:
"DST=some\directory\name"
Then your FOR command can just be this:
for /f "usebackq tokens=1 delims=" %%G in ("params.txt") do set %%G
I am not understanding why you are echoing the %dst% variable 100,000 times?
For one thing, take away the "s from around params.txt as double-quotes means string parsing, while unquoted is a list of files.
Second, try prepending params.txt with %~pd0\ to ensure the correct path, rather than changing directory.
I just created simple batch script. I want to run uninstall.exe with switches like "-q" "-splash Uninstall"
Here is the code;
#echo off
echo This script will uninstall some features.
pause
SET path=C:\Program Files\Program\uninstall.exe -q -splash Uninstall
START "" "%path%"
pause
If I run this code it gives an error:
Windows cannot find 'C:\Program Files\Program\uninstall.exe -q -splash Uninstall'
Make sure you typed the name correctly, and then try again.
If I remove switches, uninstall process starts normally.
So how can I use this swtiches in a batch file?
As an aside, don't use path as an arbitrary choice of variable name. It has a special significance in Windows (and Unix-derived systems too).
Your main problem is that you are including the switches in your quoted string, which is then treated as a whole as the executable filename. Put your quotes only around the filename, and leave the switches outside:
SET command="C:\Program Files\Program\uninstall.exe" -q -splash Uninstall
START "" %command%
(The only reason for the quotes is the fact that the pathname contains spaces.)
Also, you don't really need to use a variable at all, but I've used one since you used one.
I'm not quite sure if every program you come across will have a uninstall.exe file waiting for you in the C:\Program Files(place program name here)\ directory. Even if it does, you will probably have to control it from the GUI. However, looking at another stack overflow thread here, I would like to credit the users Bali C. and PA. for coming up with a possible solution to uninstall files using a batch file by using the registry key to find an uninstall file for windows programs. I will re-paste PA.'s code below:
#echo off
for /f "tokens=*" %%a in ('reg query hklm\software\Microsoft\Windows\CurrentVersion\Uninstall\ ^| find /I "%*"') do (
for /f "tokens=1,2,*" %%b in ('reg query "%%a" /v UninstallString ^| find /I "UninstallString"') do (
if /i %%b==UninstallString (
echo %%d
)
)
)
This code will find the uninstall file for a specific program from the registry, and then it will print out the command needed to run the uninstall file. Remove the 'echo' to just run these commands when you are sure they are correct. However, even this will probably require using the program's uninstall GUI. I don't think this would be terribly inefficient. Is there any other specific reason you want to use a batch file besides efficiency?
I hope this helps!
I'm working on a very simple bat file script that worked fine in Windows 7, but seems to be having issues in Windows 8. It relies heavily on "start /wait" to execute 1 file at a time. It seems that the "start" command works just fine. However, given the folder structure, I have referenced each item as such in a command:
start /wait ./folder1/app1.exe
start /wait ./folder2/app2.exe
start /wait ./folder3/app3.exe
While this worked just fine in W7. In Windows 8.1, this results in an error message stating: "Windows cannot find '.\folder1\app1.exe'. Make sure you typed the name correctly, and then try again."
So... Did MS replace the .\ wildcard in Windows 8 with something else? Or change it just slightly?
Yes, I know. This isn't really programming (still studying C/CPP), but any insight would be greatly appreciated.
./ is not a wildcard. * and ? are wildcards - they match any number of any characters /one any-character.
/ is a switch indicator. \ is a directory separator. Dangerous to confuse the two - it confuses cmd.
.\ means 'relative to the current directory`. Perhaps you should display the current directory using
echo %cd%
to make sure that cmd's idea of the current directory and yours agree. Also make sure the targets exist and are not hidden files.
I had the same problem with a cmd file on my usb drive.
In Windows 7 my application started with ...
START /WAIT %usbDrive%\Truecrypt\TrueCrypt.exe /volume %usbDrive%\%Container% /k %usbDrive%\Truecrypt\Truecrypt.key /cache /wipecache /quit
... but in Windows 8.1 it has not waited to put my password in the TrueCrypt screen.
As a workaround for both Windows versions this works for me fine now.
START %usbDrive%\Truecrypt\TrueCrypt.exe /volume %usbDrive%\%Container% /k %usbDrive%\Truecrypt\Truecrypt.key /cache /wipecache /quit
:CHECK
ping -n 2 localhost 1>NUL 2>NUL
TASKLIST /FI "IMAGENAME eq TrueCrypt.exe" > TrueCrypt.txt
FIND /N "TrueCrypt.exe" TrueCrypt.txt 1>NUL 2>NUL
IF %ERRORLEVEL%==0 ( GOTO CHECK ) ELSE ( DEL TrueCrypt.txt )
At first you start the program you want, then you need a mark to go back and check if your program is still running. The next thing is to wait about 2 seconds (for ping -n ... you can also use timeout). Then you can filter the tasklist with the exeutable name and write it in a check text file. With the find command you can grep in the check file... Finally the last line, if the application is not in the tasklist anymore the check text file will be deleted otherwise the cmd is jumping to the check mark.
I hope it will help
I have a DOS build script which works on one Windows Server 2008 R2 but not another. To see the symptoms on the broken machine entering either of the following at the command line:
for /f %X in ('dir /b *.txt') do #echo %X
for /f "usebackq" %X in (`dir /b *.txt`) do #echo %X
gives: "'dir /b *.txt' is not recognised as an internal or external command." while e.g.
for %X in (*.txt) do #echo %X
works fine, so the /f is not being obeyed properly. I don't believe this is the Command Extensions themselves (starting cmd /x shows the same behaviour; running them inside cmd /y on the problem server gives the normal "/f was unexpected at this time"). I have also checked the command extensions registry keys and tried "setlocal enableextensions" in the batch files.
I don't think it's relevant but differences between the servers are that the failing one is physical; its CPU doesn't have VT extensions; does have McAfee installed. As far as I know they were installed the same way though at different times.
Does anyone have any suggestions? I am stuck!
Check the COMSPEC environment variable in on the machine where it doesn't work, i.e. do echo %COMSPEC% and see what it contains (it should be %windir%\system32\cmd.exe or comparable).
Long Story:
You're detailed question ruled out all other potential possibilities (like the need to use %%X instead of %X inside batch files, as compared to the command line), like fiddling with setlocal enableextensions (or comparable switches, registry entries, etc.). And by the way, the error message would not fit.
If you get the error message "...is not recognised as an internal or external command" it is, that CMD.EXE cannot find the command you're trying to execute. Since "dir" is an internal command "this should never happen", of course.
I was able to reproduce your error doing the following:
Start CMD.EXE
Enter the following SET ComSpec=DoesNotExist
Enter the following CMD.EXE, i.e. start another, nested, CMD.EXE session. This step is required, in a running CMD.EXE session, the change to ComSpec seems to go unnoticed.
In the new CMD.EXE session enter your command (e.g. for /F %x in ('dir /b') do #echo%x), you should get the error you see. Note if you just enter dir it will still work, so you have to have that "indirect" execution via, e.g., a for loop. Funny.
Note that this was all done to reproduce what you are seeing, the reasons exact environmental or setup conditions that lead to this behavior on your system might be different, however the fact that the ComSpec environment variable refers to something other than CMD.EXE should be the same.
In a batch file you have to use double-percents i.e. %%X.
At the command line single percents are fine.
As to why it works on one machine, not sure, perhaps its somehow being run via 16 bit DOS on the machine which works? Or it was a different test that appears to work without the variable substituion working.