[Martin H]

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...

This post has been edited by Martin H: 05 March 2010 - 09:26 AM

[submix8c]

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)...

This post has been edited by submix8c: 05 March 2010 - 11:40 AM

[g-force]

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

[Sp0iLedBrAt]

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.

[Martin H]

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...

This post has been edited by Martin H: 06 March 2010 - 06:40 AM

[g-force]

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.

[Jito463]

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.

[Yzöwl]

g-force, on 06 March 2010 - 08:01 AM, said:

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!

[Martin H]

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:

Quote

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.micro...y/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.

This post has been edited by Martin H: 06 March 2010 - 09:56 AM

[submix8c]

Martin H, on 05 March 2010 - 09:22 AM, said:

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. 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 )

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...

This post has been edited by submix8c: 06 March 2010 - 10:07 AM

[Martin H]

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'...

This post has been edited by Martin H: 06 March 2010 - 11:13 AM

[Martin H]

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...

This post has been edited by Martin H: 06 March 2010 - 06:11 PM

[Martin H]

...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!

[submix8c]

... 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!

This post has been edited by submix8c: 07 March 2010 - 10:39 AM

[Martin H]

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...

This post has been edited by Martin H: 08 March 2010 - 01:03 PM

[cluberti]

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).

[Martin H]

Thanks, didn't knew that!

[Yzöwl]

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

[Martin H]

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

@all

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

Quote

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):

Quote

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.

[g-force]

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.