• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
Sign in to follow this  
Followers 0
Martin H

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

33 posts in this topic

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
0

Share this post


Link to post
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
0

Share this post


Link to post
Share on other sites

I usually use "start /wait" in a .cmd - and it works.

0

Share this post


Link to post
Share on other sites

I only use "start /wait" in a .cmd file for installing stuff from the $OEM$ folder. It hasn't failed me so far. Truth be told, .cmd files have always been more understandable to me in terms of syntax.

0

Share this post


Link to post
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
0

Share this post


Link to post
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.

0

Share this post


Link to post
Share on other sites

Just tested, and without /WAIT in my .cmd file, the programs all launched simultaneously. Added /WAIT, and the programs only ran one at a time. Sorry, but you're mistaken.

0

Share this post


Link to post
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!

0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
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!

0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
Share on other sites

While a .bat file will run under cmd.exe on XP and higher (always), there are command extensions and variables that work in a .cmd and not a .bat, even when executed in cmd.exe (it is done this way on purpose for backwards compat).

0

Share this post


Link to post
Share on other sites

If you want a little more light reading, take a look here.

0

Share this post


Link to post
Share on other sites

Thanks for the link, mate! Nice detailed info there! :)

@all

From the above article(just to prove what i allready stated):

Notice that the operation of the START command differs from the default command shell sequence:

First, the START command never waits for the command to complete.

[...]

As described above, the START command does not wait for the new command to complete; a new command prompt appears immediately and new commands can be executed at once. When used in a script, the next line in the script executes immediately. The /WAIT switch makes the START command wait for the command to complete before continuing. This switch applies to all commands and applications, including GUI applications.

And about cmd.exe/command.com, then there was something i didn't knew(but submix8c did, if you read his earlier post):

The 16-bit MS-DOS shell (COMMAND.COM) that ships with Windows NT is specially designed for Windows NT. When a command is entered for execution by this shell, it does not actually execute it. Instead, it packages the command text and sends it to a 32-bit CMD.EXE command shell for execution. Because all commands are actually executed by CMD.EXE (the Windows NT command shell), the 16-bit shell inherits all the features and facilities of the full Windows NT shell.
0

Share this post


Link to post
Share on other sites

Maybe I miss the point due to my poor english. That`s what I understand (written in a .cmd):

1.) start /wait MySetup.exe ---> executes and waits until end of "MySetup.exe", then executes the next line

2.) start MySetup.exe ---> executes "MySetup.exe", doesn`t wait and executes immediatly next line of the .cmd

3.) no switch at all ---> same as 1.), because "wait" is set by default

Please correct me if I`m wrong.

0

Share this post


Link to post
Share on other sites

no switch at all would be the same as 2

I think you mean no start.

0

Share this post


Link to post
Share on other sites

@g-force

Exactly, mate! :) (as X stated, if you by "no switch" means no START command in no.3, which i'm sure you do...)

Edited by Martin H
0

Share this post


Link to post
Share on other sites

agree with g-force

Think this is a situation where some apps will continue and some will not, I've tried removing the /wait and turns into a nightmatre doing 20-30 apps. even on Seven 64 bit

0

Share this post


Link to post
Share on other sites
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.
Additionally, it may depend on the app in question as to how it "exits" and/or whether it calls other subroutines (e.g. dual-extract/execute... one-inside-the-other)???

Perhaps this is the reason the original recommendation was "start /wait" (cover all the bases, regardless).

Ennyhoo, a good learning experience with relevant information as to "how/why".

Aaannnd... Edit!!!

I re-read above; only says "removed wait"(See Next Post/Prev Posts)...

Edited by submix8c
0

Share this post


Link to post
Share on other sites

agree with g-force

Think this is a situation where some apps will continue and some will not, I've tried removing the /wait and turns into a nightmatre doing 20-30 apps. even on Seven 64 bit

You havent read what I have stated throughout the whole thread then...

"start /wait" makes ZERO difference in BAT/CMD files...

YES, some apps dosent wait, but thats besides the point, as "start /wait" dosent fix it...

Lastly, you should not remove "/wait", but "start /wait"...

@submix8c

"start /wait" dosent cover the bases and are always 100% redundant in cmd/bat files...

Edited by Martin H
0

Share this post


Link to post
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
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.