Re: Interactive commands cant be backgrounded if run from bashrc
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 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, CWRUc...@case.edu http://tiswww.cwru.edu/~chet/
Re: Interactive commands cant be backgrounded if run from bashrc
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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Interactive commands cant be backgrounded if run from bashrc
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? And it sounds like some things, like enabling job control, do not happen until that happens? Also, I understand this is the bash bugs mailing list.. If there is a better place for me to direct these questions, please feel free to redirect me. Thank you,Cheshire On Thu, 02 Sep 2021 15:57:51 -0400 Chet Ramey wrote On 9/2/21 12:15 PM, C. Yang wrote: > However, is it possible that there may be further unexpected consequences, > since bash is still waiting to complete initialization this entire time? > > For instance, if I stop and background emacs, then I find myself back to > the bash > shell. But technically, bash is still waiting for .bashrc to complete. This is not correct. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu http://tiswww.cwru.edu/~chet/
Re: Interactive commands cant be backgrounded if run from bashrc
On 9/2/21 12:15 PM, C. Yang wrote: > However, is it possible that there may be further unexpected consequences, > since bash is still waiting to complete initialization this entire time? > > For instance, if I stop and background emacs, then I find myself back to > the bash > shell. But technically, bash is still waiting for .bashrc to complete. This is not correct. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Interactive commands cant be backgrounded if run from bashrc
On Thu, Sep 02, 2021 at 12:15:35PM -0400, C. Yang wrote: > I can confirm that adding `set -m` before the emacs command in .bashrc results > > in the behavior I want with CTRL+Z. As I understand, `set -m` will enable job > > control features. This suffices for my use case. > > > > However, is it possible that there may be further unexpected consequences, > > since bash is still waiting to complete initialization this entire time? > > > > For instance, if I stop and background emacs, then I find myself back to the > bash > > shell. But technically, bash is still waiting for .bashrc to complete. No, you're mistaken. When you suspend emacs, bash finishes reading the .bashrc file, and *then* it prints the shell prompt. The fact that you see the prompt means bash has completed its startup.
Re: Interactive commands cant be backgrounded if run from bashrc
Hi Dale and Chet, Thank you both for your responses and clarifications. Yes, I would like emacs to behave as if I had typed it in the command line, in particular, to be able to stop and background it in the usual way. I can confirm that adding `set -m` before the emacs command in .bashrc results in the behavior I want with CTRL+Z. As I understand, `set -m` will enable job control features. This suffices for my use case. However, is it possible that there may be further unexpected consequences, since bash is still waiting to complete initialization this entire time? For instance, if I stop and background emacs, then I find myself back to the bash shell. But technically, bash is still waiting for .bashrc to complete. It sounds like some initialization steps only happen after .bashrc completes, so this terminal session could be missing other features. (I don't know enough about bash, though, to know if this concern is warranted.) Perhaps what I really want is to automatically run commands after bash initializes completely. Perhaps I'm going about this the wrong way entirely by trying to use .bashrc for this purpose? Finally, Dale had written: > Uh, "backgrounding" *is* "run it simultaneously*. I think what you mean > is "stop and background it", which is what ctrl-Z does. You are correct, and I appreciate the clarification. However - and this may be specific to emacs or editor programs - when I run `emacs &` when job control is enabled, it does appear to both background and stop the process. Again, this seems to be a feature specific to emacs, as you are right that typically just backgrounding with & will not also stop the process. I would of course appreciate further clarifications if I've misunderstood. Respectfully, Cheshire "When face to face with a difficulty, you are up against a discovery." - Lord Kelvin On Thu, 02 Sep 2021 10:25:15 -0400 Chet Ramey wrote On 9/1/21 2:10 PM, C. Yang wrote: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Description: > > Whenever I start my session, I'd like to automatically open emacs to a > specific file. > > So, I added the emacs command to the bottom of my ~/.bashrc file. This > opens emacs > > correctly when I start the session. > > > > Normally, when I start emacs, I can background the process with CTRL+Z, and > foreground > > with `fg` command. When emacs is started from .bashrc as above, pressing > CTRL+Z does > > not correctly background the process. Instead, the terminal session goes > blank and > > becomes unresponsive. Bash doesn't initialize job control until after reading the startup files, which are executed in a nominally non-interactive environment. You can force that initialization by running `set -m'. It may work for your purposes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU mailto:c...@case.edu http://tiswww.cwru.edu/~chet/
Re: Interactive commands cant be backgrounded if run from bashrc
On 9/1/21 2:10 PM, C. Yang wrote: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Description: > > Whenever I start my session, I'd like to automatically open emacs to a > specific file. > > So, I added the emacs command to the bottom of my ~/.bashrc file. This > opens emacs > > correctly when I start the session. > > > > Normally, when I start emacs, I can background the process with CTRL+Z, and > foreground > > with `fg` command. When emacs is started from .bashrc as above, pressing > CTRL+Z does > > not correctly background the process. Instead, the terminal session goes > blank and > > becomes unresponsive. Bash doesn't initialize job control until after reading the startup files, which are executed in a nominally non-interactive environment. You can force that initialization by running `set -m'. It may work for your purposes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Interactive commands cant be backgrounded if run from bashrc
On Wed, Sep 01, 2021 at 09:28:55PM -0500, Dennis Williamson wrote: > On Wed, Sep 1, 2021, 8:42 PM Greg Wooledge wrote: > > I tested with "set -m" and "vim & fg" just now, and it appeared to work. > > Do processes started in .bashrc have a terminal? I would suspect that > something without a try would either complain or work differently. I'll > have to play around with it. As long as bash is started in a terminal: yes. I also tested with "set -m" and "vim" in my .bashrc file. Everything worked as I expected it to. I launched a terminal (urxvt), and it opened with vim running. I was able to Ctrl-Z it. It looks like this: [1]+ Stopped vim unicorn:~$ jobs [1]+ Stopped vim unicorn:~$ ps PID TTY TIME CMD 2100754 pts/30 00:00:00 bash 2100756 pts/30 00:00:00 vim 2100757 pts/30 00:00:00 ps unicorn:~$ I could also "fg" it, and exiting from vim put me into an interactive bash shell. Absolutely no surprises at all.
Re: Interactive commands cant be backgrounded if run from bashrc
On Wed, Sep 1, 2021, 8:42 PM Greg Wooledge wrote: > On Wed, Sep 01, 2021 at 09:37:02PM -0400, Dale R. Worley wrote: > > "C. Yang" writes: > > > emacs test.txt & > > > > > > fg > > > > > bash: fg: no job control > > > It sounds like Bash doesn't activate the job-control features until > > .bashrc is completed. > > Well, there's an easy fix for that. Just put "set -m" before the > last two commands. > > I tested with "set -m" and "vim & fg" just now, and it appeared to work. > > Do processes started in .bashrc have a terminal? I would suspect that something without a try would either complain or work differently. I'll have to play around with it.
Re: Interactive commands cant be backgrounded if run from bashrc
On Wed, Sep 01, 2021 at 09:37:02PM -0400, Dale R. Worley wrote: > "C. Yang" writes: > > emacs test.txt & > > > > fg > > > bash: fg: no job control > It sounds like Bash doesn't activate the job-control features until > .bashrc is completed. Well, there's an easy fix for that. Just put "set -m" before the last two commands. I tested with "set -m" and "vim & fg" just now, and it appeared to work.
Re: Interactive commands cant be backgrounded if run from bashrc
"C. Yang" writes: > This may be because the bashrc file is still running, and bash itself > perhaps does not finish initializing until everything in the bashrc > completes. This may be why CTRL+Z does not work correctly (it might > require bash to finish initializing first) I'm sure that's the problem in your first case: If you put "emacs foo.bar" in .bashrc, it instructs Bash to run Emacs, wait until the job completes, and implicitly: finish processing .bashrc, then start listening to the terminal. It gets messier because the processing of ctrl-Z is done in the kernel, manipulating the state of processes, but it's possible that Bash doesn't activate job control in the terminal handler until processing .bashrc is finished. In any case, I wouldn't expect this case to work like you want. > emacs test.txt & > > fg > The first line, instead of backgrounding emacs, appeared to run it > simultaneously with bash. This had the consequence that both bash and > emacs were taking the same Uh, "backgrounding" *is* "run it simultaneously*. I think what you mean is "stop and background it", which is what ctrl-Z does. > bash: fg: no job control It sounds like Bash doesn't activate the job-control features until .bashrc is completed. It sounds like what you want is for the last thing .bashrc (or more likely, .bash_login) does is to start an Emacs that acts exactly as if you typed "emacs" at the prompt. In particular, you want to be able to background it in the ordinary way, which seems to require that Bash has finished processing .bashrc. Dale
Interactive commands cant be backgrounded if run from bashrc
From: cheshire (he...@cheryllium.com) To: mailto:bug-bash@gnu.org Subject: Interactive commands cant be backgrounded if run from bashrc Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux cyang_2021 4.4.0-19041-Microsoft #1151-Microsoft Thu Jul 22 21:05:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: Whenever I start my session, I'd like to automatically open emacs to a specific file. So, I added the emacs command to the bottom of my ~/.bashrc file. This opens emacs correctly when I start the session. Normally, when I start emacs, I can background the process with CTRL+Z, and foreground with `fg` command. When emacs is started from .bashrc as above, pressing CTRL+Z does not correctly background the process. Instead, the terminal session goes blank and becomes unresponsive. This may be because the bashrc file is still running, and bash itself perhaps does not finish initializing until everything in the bashrc completes. This may be why CTRL+Z does not work correctly (it might require bash to finish initializing first) While trying to find a workaround, we tried to start the process in background, and then foreground it, within the bashrc. So instead of `emacs test.txt`, we tried: emacs test.txt & fg The first line, instead of backgrounding emacs, appeared to run it simultaneously with bash. This had the consequence that both bash and emacs were taking the same keyboard input and trying to render to the same screen. The second line crashes with the error: bash: fg: no job control (Probably doesn't need to be said, but these commands work if taken out of the bashrc, and run manually in the shell after bash is allowed to finish initialization.) Repeat-By: 1. Add the following line to bottom of your bash init file: emacs test.txt # doesn't matter 2. Start a new session (let it open emacs too) 3. Press CTRL+Z
