Start background process under bash

[Joe Burpee]

Bob McGowan wrote:
> First, I'm adding the cygwin list back in the CC field.  This is
> "normal" for discussion, so others can add or modify (and correct ;-)
> suggestions, etc.

Hey, no problem Bob.  You mailed me off-list, so I assumed you didn't
want to go public with your comments.

> You mention using the DOS box "start /b" to get a process running in the
> bash background.  Since the start command is part of the CMD.EXE and not
> of bash, I'm not sure I understand what you are doing.  For a background
> process in bash, you would run:
> 
>         bash-02$ command args... &
>         bash-02$
> 
> which has always worked for me.  The ampersand tells bash to start the
> command but not wait for it to exit.

Right, and as I mentioned I'm getting an annoying "illegal op" pop-up in
Win9x, although the child process does run ok.  And in NT4 the parent
just sits there and waits, as though the "&" wasn't there.

> Using start in a cmd prompt sort of emulates UNIX background processes,
> but I believe the process structure of windows results in a brand new,
> unrelated to the original, set.  (I am not an expert on this, though.
> Perhaps others could provide a more precise explanation.)  Suffice it to
> say, I can do the following:
> 
>         bash-02$ cmd /c "start bash"
> 
> and get a brand new window with a bash command prompt, where the new
> bash process (in cygwin/unix terms) is its own parent.  Normally, a
> background process will have a parent PID equal to the process that
> started it.

This is ok with me as I don't want the calling process to manage the
child(ren).  (Just spawn, and say goodbye.)  And I can live with the
separate window, for the sake of getting rid of the stupid pop-up in
Win9x.

> If I add the /b option to the start command in the above
> example,  I get 2 bash shells competing for the single input focus.

Yup.  This seems consistent with the sparse documentation I've found on
cmd.exe.

> A ps -f in a separate shell still shows that the bash running via the
> start command is its own parent (so not a "true" background process) and
> is not manageable using the bash 'jobs' command or the '%#' background
> jobs referencing features.

Thanks for elaborating this stuff.  As I mentioned before, I can live
with the "command.com /c start ..." fix in Win9x, but even that doesn't
work with cmd.exe on my client's NT4 installation.  There the "/b"
switch does allow me to launch a separate process, but even then I'm
running into conflicts; e.g. I can use the (grand)parent shell, but
readline (filename completion in particular) doesn't work.

Anyway, as I said these cmd.exe/command.com workarounds may be somewhat
off-topic, but I would be really interested if anyone can suggest why
the bash "&" does not seem to be working in all the Win environments
I've tried.  No doubt I'm doing something wrong, but I have no idea
what.  I'm used to Linux (where the script  works every time, of
course).

Joe

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com