Earnie Boyd wrote, quoting Paul Dobbs:
>> It doesn't seem to have a problem with lines like:
>> "c:Program Files\Microsoft Office\OFFICE11\WINWORD.exe" $@
>> So that is what I am using a present. Two questions:
>> 1. What is the difference between using start and not using start (like
>> the example above)?
`start' is pretty much the Windoze analogue of adding a free standing
ampersand to the *end* of the command line in *nix; it places the process
being started in the background, allowing the shell to get immediate
control of the console again. Thus, Earnie's explanation...
> Winword doesn't open the console so it allows the return of your MSYS
> window without needing start. If the program were to use the console
> you would need to use start to create a new console to allow the MSYS
> console to become free.
...is tantamount to saying that WINWORD is coded in a fashion which
causes it to place *itself* in background, from the off; (there are
some *nix applications which behave similarly). You won't notice
any difference, with such applications, whether or not you use
>> 2. I'm working on a script that needs to start up a couple of programs
>> and wait until the user finishes with them and closes them befor
>> continuing. Is there a way other than putting a read after the lines
>> that start the program to accomplish this?
Yes. The conventional *nix way would be `wait'; it works in MSYS too.
>> The read works fine, this is
>> mostly curiousity.
> From my answer to your first question, it should be obvious that if
> you open the console then MSYS would wait until it has control of the
You don't need to do that. If your script invokes foreground tasks,
it will wait for them anyway; to wait for the last background task you
started, just add a `wait', (or `wait $!'), after the command which
starts it, so, staying with WINWORD as an example:--
'c:/Program Files/Microsoft Office/Office/winword' "$@"
# `winword' always forks a background process, even if we don't
# explicitly request it, so wait for it to finish...
# now we can do whatever we need to, after `winword' has finished.
BTW, it doesn't matter whether you use backslashes, as in your example,
or regular slashes, as I have shown. Just remember that backslash has
special meaning to the UNIX shell, (which you are using here), so you
need to be careful with quoting; IMO, using a regular slash is cleaner,
and less likely to cause confusion.
Also note that, when you use `$@' to pass script arguments on to a child
process, it really is good practice, as Earnie pointed out yesterday, to
wrap it in *double* quotes. If you don't, word splitting may occur where
you don't want it, and double quotes should prevent that; (*should*, means
*will* on *nix, but since argument quoting is broken in too many Windoze
programs -- `start', for example -- it can't be guaranteed for MSYS).