Re: Interactive commands cant be backgrounded if run from bashrc

[Chet Ramey]

On 9/2/21 5:06 PM, C. Yang wrote:
> Could you please explain why? I thought the reason for the behavior 
> described in my original post was that bash does not complete 
> initialization until .bashrc completes, which doesn't happen until the 
> emacs process started from within it completes? 

OK. You said you enabled job control (set -m), started emacs, stopped it
and put it into the background. As soon as you background the process,
the shell goes ahead and reads and executes the next command, which, since
this is the last thing in .bashrc, results in EOF. Once the shell is
finished reading commands from .bashrc, it completes initialization and
continues by printing the interactive prompt.

The same thing effectively happens if you start emacs in the background
after enabling job control: since it will not have access to its
controlling terminal (it is in a different process group from the
terminal's process group) it will get a SIGTSTP when it tries to read from
the terminal and stop. Once the shell starts the process in the background,
it goes on immediately and doesn't wait.

If you try to start emacs in the foreground without enabling job control,
you will not be able to use job control signals to manipulate its state,
and the shell will have to wait for it to terminate before it can go on
and finish reading from .bashrc, as it would with any other foreground
process.

If you start emacs in the background without enabling job control, the
shell will complete reading and executing commands from .bashrc as
described above, and go on with normal interactive execution. Bash does
not make itself a session leader, or allocate a new controlling terminal,
so it and the backgrounded emacs will both have access to the controlling
terminal and will fight over input.

In the first two scenarios, the job you started by invoking emacs and
backgrounding it will eventually complete on its own, and the shell will
reap the terminated process, as part of the normal interactive shell
execution.

> And it sounds like some 
> things, like enabling job control, do not happen until that happens?

Unless you force job control using `set -m', as you say you did.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/