Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

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

- - - - -

  • Please log in to reply
32 replies to this topic

#1
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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, 05 March 2010 - 09:26 AM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image



How to remove advertisement from MSFN

#2
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,508 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
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, 05 March 2010 - 11:40 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#3
g-force

g-force

    Tester

  • Member
  • PipPipPipPip
  • 583 posts
  • Joined 20-June 07
  • OS:XP Pro x86
  • Country: Country Flag
I usually use "start /wait" in a .cmd - and it works.

g-force @ Win-Lite.de
Make sure to always start with a fresh copy of your CD files/folders,
do all your work in one nLite session and integrate only one SP.
Please report when you have a solution, so others can benefit.


#4
Sp0iLedBrAt

Sp0iLedBrAt

    MSFN Addict

  • MSFN Sponsor
  • 1,706 posts
  • Joined 19-March 09
  • OS:XP Pro x86
  • Country: Country Flag
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.

#5
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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, 06 March 2010 - 06:40 AM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#6
g-force

g-force

    Tester

  • Member
  • PipPipPipPip
  • 583 posts
  • Joined 20-June 07
  • OS:XP Pro x86
  • Country: Country Flag
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.

g-force @ Win-Lite.de
Make sure to always start with a fresh copy of your CD files/folders,
do all your work in one nLite session and integrate only one SP.
Please report when you have a solution, so others can benefit.


#7
Jito463

Jito463

    Advanced Member

  • Member
  • PipPipPip
  • 442 posts
  • Joined 01-July 04
  • OS:none specified
  • Country: Country Flag
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.
Help us help YOU! <-- Click here

#8
Yzöwl

Yzöwl

    Wise Owl

  • Super Moderator
  • 4,072 posts
  • Joined 13-October 04
  • OS:Windows 7 x64
  • Country: Country Flag

Donator

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!

#9
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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.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.

Edited by Martin H, 06 March 2010 - 09:56 AM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#10
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,508 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

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, 06 March 2010 - 10:07 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#11
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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, 06 March 2010 - 11:13 AM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#12
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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, 06 March 2010 - 06:11 PM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#13
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
...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!

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#14
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,508 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
... 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, 07 March 2010 - 10:39 AM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#15
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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, 08 March 2010 - 01:03 PM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#16
cluberti

cluberti

    Gustatus similis pullus

  • Supervisor
  • 11,021 posts
  • Joined 09-September 01
  • OS:Windows 8.1 x64
  • Country: Country Flag

Donator

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).
MCTS Windows Internals, MCITP Server 2008 EA, MCTS MDT/BDD, MCSE/MCSA Server 2003, Server 2012, Windows 8
--------------------
Please read the rules before posting!
Please consider donating to MSFN to keep it up and running!

#17
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
Thanks, didn't knew that! :)

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#18
Yzöwl

Yzöwl

    Wise Owl

  • Super Moderator
  • 4,072 posts
  • Joined 13-October 04
  • OS:Windows 7 x64
  • Country: Country Flag

Donator

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

#19
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
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.


/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#20
g-force

g-force

    Tester

  • Member
  • PipPipPipPip
  • 583 posts
  • Joined 20-June 07
  • OS:XP Pro x86
  • Country: Country Flag
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.

g-force @ Win-Lite.de
Make sure to always start with a fresh copy of your CD files/folders,
do all your work in one nLite session and integrate only one SP.
Please report when you have a solution, so others can benefit.


#21
-X-

-X-

    Member

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,425 posts
  • Joined 08-January 04
  • OS:XP Pro x86
  • Country: Country Flag

Donator

no switch at all would be the same as 2
I think you mean no start.
[ Download all Windows XP Post SP3 High-Priority Updates with a simple double click @ xdot.tk Posted Image ]
If someone helps you fix a problem, please report back so they and others can benefit from the solution. Thanks!

#22
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified
@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, 11 March 2010 - 10:58 AM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#23
maxXPsoft

maxXPsoft

    MSFN Master

  • Developer
  • 2,878 posts
  • Joined 14-November 03
  • OS:Windows 7 x64
  • Country: Country Flag
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
Download ++> Windows 7 + 8 Unattended DVD + App Installer + Services Disabler + Load All Button + XML Creator
Jump2Reg - Registry: - Oct 4, 2013 - Version 3.0.4 - 98, ME, NT, 2K, XP, VISTA, Seven, Windows 8+ and 32 or 64 bit

XP Unattended CD/DVD creator - Version 4.1.7
Sample xml + Setupcomplete + Add Right click .wim Windows 7 or Windows 8/8.1

#24
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,508 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

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, 12 March 2010 - 05:35 PM.

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#25
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 791 posts
  • Joined 24-November 06
  • OS:none specified

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, 12 March 2010 - 04:29 PM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image





4 user(s) are reading this topic

0 members, 4 guests, 0 anonymous users