Mail Archives: cygwin/2000/01/25/18:51:03
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 AT sourceware DOT cygnus DOT com
- Raw text -