Jump to content

About cmd's 'start "" /wait' command


Recommended Posts

OK, in my own experience, then 'start "" /wait' has never made a difference(just used ping instead when needed i.e. when a process branches out to another one), even though the MSFN unattended guide and many other places states so...

However, i thought that it couldn't be right that msft had made a parameter which didn't made a difference, so i was puzzled about it...

Now i've finally found out what the deal is about this...

the CMD prompt will by default not wait for a win32 gui app to terminate before returning to the cmd prompt again UNLESS it's run from a NT command script!

So, this means that the parameter is thought to be used ONLY when running from the cmd prompt and NOT from a NT command script!

Check it out for yourself if in doubt... :)

Anyway, just wanted to add that you can all now remove your 'start "" /wait' commands from your NT command scripts, as they are totally redundant...

Edited by Martin H
Link to comment
Share on other sites


Hmmm... as opposed to the NT-based COMMAND.COM (compatible DOS processor)...

ComputerHope is a wealth of information...

edit - Curiosity... Does this happen if you write the scripts as BAT instead of CMD? I'm thinking that the original assertion holds true if CMD.EXE processes a BAT file (treats it as DOS-compatible)...

Edited by submix8c
Link to comment
Share on other sites

Everyone, please re-read my post again!

I haven't tested with bat, as i'm not interested in that... The correct extension for NT command scripts(which this thread is about!) is cmd and not bat...

Also, please understand that i'm not stating that 'start "" /wait' dosen't work, i'm just stating that from a NT command script, then the command is redundant, as "waiting" is enabled by default!

Of course it dosen't hurt to leave that command in either, but again, i'm just stating that it's redundant...

If an app dosen't finish before the next starts in a NT command script, then 'start "" /wait' will not make a difference whatsoever, and instead e.g. 'ping -n 10 localhost' can be used instead of external 3'rd party tools...

This forum, MSFN unattended guide and entire web is filled with statements about 'start "" /wait' will enable "waiting" in CMD files and i'm just trying to end that myth with this thread...

Edited by Martin H
Link to comment
Share on other sites

If I don`t use Start /wait im my CMD, all lines are executed without waiting.

So it makes a difference for me. There is no waiting enabled by default in a CMD.

Here's a thought!

Each time you use START, you are actually opening a new CMD window, if this is considered as a new Command Prompt session then according to MartinH it will not wait by default for the app to close!

Try therefore to run some tests using combinations of STARTs /I and /B switches without the /WAIT switch and see if it makes a difference to you in your situation.

Post back the results!

Link to comment
Share on other sites

For me then NT command scripts always wait! (if not, then it's because an app starts another process while ending the previous one, and in that case, adding 'start /wait' dosen't help)

After having for years noticed that for me, then 'start /wait' or no 'start /wait' didn't made a difference, and then also after having seen the following text yesterday on a technet article about the 'start' command:

When you run a 32-bit graphical user interface (GUI) application, cmd does not wait for the application to quit before returning to the command prompt. This new behavior does not occur if you run the application from a command script.

Source: http://technet.microsoft.com/en-us/library/bb491005.aspx

Then i did the following to test it out...

Open a command prompt and enter 'notepad' and then minimize notepad and check the command prompt; dose it wait or not; no it dosen't wait..

Now do the same again but with added 'start /wait' and see that it does wait...

Then now make a NT command script with the content: 'notepad' and run it and what happens; the NT command script is still open after notepad has started and the NT command script is paused on the 'notepad' line which means that waiting IS enabled from NT command scripts...

I have lots of NT command scripts and no one uses 'start /wait'... For example one script starts nLite unattended and silent and through the entire process the script is waiting and only when nLite ends, then the script continues to the next line to make ISO and copy the ISO to backup folder etc.

Edited by Martin H
Link to comment
Share on other sites

the CMD prompt will by default not wait for a win32 gui app to terminate before returning to the cmd prompt again UNLESS it's run from a NT command script!
I think the keyword here is "GUI". This includes any (?) Hotfix packages or any program that normally waits for a response, but has been over-ridden to allow Quiet. :unsure: Otherwise, a simple program (e.g. "ping") doesn't require this (not a GUI) which in and of itself retains control. "Start/Wait" is strictly for retaining control within said CMD/BAT until GUI-end. This may also apply (depending on content) to calling a Sub-CMD/BAT (also :unsure: )

So... the original assertion is somewhat correct (as it all depends on the process and/or program in question), but not entirely since in other cases it will be required.

(keyword=GUI)

edit @Martin-H - hmmm late post; will have to test a few as above... been stuck in BAT-mode for a while...

Edited by submix8c
Link to comment
Share on other sites

Yes, GUI is keyword as console apps and internal cmd commands always have waiting enabled(in the NT command processor!)...

Still, the 'start /wait' command is IMHO only meant for console usage and not from NT command scripts...

Look at the following scenario:

Try to run a big app like VMware or dotNET-v2.0 silently from a NT command script without 'start /wait'; what happens; waiting is enabled untill end... Then try to run it from a command prompt this time; what happens; waiting isn't enabled at all, and this "non-waiting" behaviour can then be over-ridden by adding 'start /wait'...

Edited by Martin H
Link to comment
Share on other sites

As Yzöwl correctly stated, then if using the start command without the '/wait' parameter from a NT command script, then "batch-mode-waiting" is over-ridden, so when testing, then use:

'appname.exe /switch'

Vs.

'start "" /wait appname.exe /switch'

,and not

'start appname.exe /switch'...

This then also means that if you e.g. want to run an app e.g. minimized from a NT command script, by using the 'start' command, then you can use the '/wait' parameter to enable waiting, as the 'start' command over-rides that without it, but again, i was stating that 'start "" /wait' was redundant in NT command scripts for the use of enabling waiting, as waiting is always enabled by default for NT command scripts, but not that the 'start' commands '/wait' parameter was redundant...

Edited by Martin H
Link to comment
Share on other sites

...Just wanted to add that i've just tested with the MS-DOS batchfile extension i.e.: .BAT(as oppossed to NT command scripts CMD extension), and still the same result i.e. "waiting" is enabled by default!

That's pretty obvious as the NT command processor cmd.exe also runs those files, which actually kinda surpriced me, as i thought that the MS-DOS command processor command.com would run those, but i've never before runned .BAT files on a NT system, since I generally always preffer to use the "correct" extension, so that's why i didn't knew anything about it...

Anyway, could the people that posted that i was wrong please re-test by following my previous instructions and post back, thanks!

Link to comment
Share on other sites

... probably CMD.EXE - Check! (processes BAT/CMD)

... COMMAND.COM (the NT-version of "not-NT"), maybe not (processes BAT-only old-style?)...

(just to distinguish and embellish the thread's documented findings...)

"Format->Create an MS-DOS Startup Disk"

(when START->RUN->COMMAND.COM does CMD.EXE execute it at a lower level or does it run directly?)

(note - I haven't personally tried, just presenting additional test cases...)

Peace, brothers/sisters!

Edited by submix8c
Link to comment
Share on other sites

I've read-up on it(on this other subject)...

.BAT's are run fully by cmd.exe...

The recommendation for using the .CMD extension is for avoiding the file to be able to run on Win95/98 systems(e.g. command.com will fail to set %errorlevel% after certain commands.)...

command.com is only supplied on NT systems for the 'compatibility option'(running old apps) and for making a MS-DOS startup disk...

As for rapping up the main topic of this thread:

Everyone please understand that "waiting" is enabled by default in CMD/BAT files, so the use of 'start "" /wait' is redundant. In the cases where "waiting" dosen't seem enabled, then 'start "" /wait' will not help, as the reason is the program has started another process while clossing the previous and so instead e.g. ping can be used...

Edited by Martin H
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...