Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
Martin H

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

Recommended Posts

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

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.

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.

Share this post


Link to post
Share on other sites
Guest

no switch at all would be the same as 2

I think you mean no start.

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

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

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

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

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

Agree - I use "setup.cmd" in some of my Silent-WinRAR-SFX (I usually install with this method).

Some Setups won`t install (or stuck) without that "start /wait" because of false or "too fast" execution.

I´m sure it makes a difference in a .cmd.

Share this post


Link to post
Share on other sites

Well, then lets agree to disagree then...

Btw, please give me an example of ANYTHING where "start /wait" makes a difference in cmd, and i will test it out...

Also, so you guys are not believing msft when they say in their technet article>

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.

Console apps never waits obviously, but gui apps are gui apps no matter if they are silently executed or not...

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.

And hence, the /wait switch when using it... Said in another way, the /wait switch modifies the start commands normal behaviour, but NOT the command shells behaviour in any way...

If that was the case, then there would instead be a switch for cmd.exe itself to change that behaviour obviously...

Anyway, im done with this now if not getting an example, as i have proven it previously in this thread both with tests and technet quotes, so unless im givin an example to prove wrong, i dont want to continue repeaing myself here...

Edited by Martin H

Share this post


Link to post
Share on other sites

Then explain why this cmd waits until notepad is closed before the message appears.

Perhaps I have been reading this wrong, but this Cmd script from what I read should

not wait for notepad to close before the message appears. That is not the case it

waits until notepad closes before the message appears.

@Echo OffCLSMode 55,9
Echo.Start /wait notepadCLSEcho.Echo This does not show until Notepad is closedpause

Share this post


Link to post
Share on other sites

Then explain why this cmd waits until notepad is closed before the message appears.

Perhaps I have been reading this wrong, but this Cmd script from what I read should

not wait for notepad to close before the message appears. That is not the case it

waits until notepad closes before the message appears.

What happens if you run this?:

@Echo Off

CLS

Mode 55,9

Echo.

notepad.exe

CLS

Echo.

Echo This does not show until Notepad is closed

pause

Anything different happening form the one you posted? :unsure:

jaclaz

Share this post


Link to post
Share on other sites

THANK YOU jaclaz, my friend! :)

Finnaly someone who understands what i've been saying for two pages now... (sorry, Yzöwl as ussual also does...)

Please everyone, READ before posting!!!

Edit: I didn't even have to, but anyway i've just tested this and obviously you know what the result was...

Edited by Martin H

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  

  • Recently Browsing   0 members

    No registered users viewing this page.

×