Re: Interactive commands cant be backgrounded if run from bashrc

[C. Yang]

            Ah, I understand it now. Thanks for explaining it to me so 
patiently. This also means my issue is resolved. Thank you all again for your 
help!Best, Cheshire---- On Thu, 02 Sep 2021 18:44:36 -0400  Chet 
Ramey<chet.ramey@case.edu> wrote ----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/