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: Squiggly heredoc - new feature request
Hello. Thank you. If you don't want to implement it yourself, I am at your disposal. :) Just let me now. Best regards Přemysl On 9/1/21 4:11 PM, Chet Ramey wrote: On 8/31/21 3:25 PM, Lawrence Velázquez wrote: On Tue, Aug 31, 2021, at 4:02 AM, Lawrence Velázquez wrote: ksh does not blindly remove all leading whitespace For the curious, this is how ksh(1) describes it: If '#' is appended to '<<', then leading spaces and tabs will be stripped off the first line of the document and up to an equivalent indentation will be stripped from the remaining lines and from 'word'. A tab stop is assumed to occur at every 8 columns for the purposes of determining the indentation. I will consider this for a future version. OpenPGP_0x2FD4F23C65C1A5F0_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
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: LINENO is affected by sync
Not sure I can go with that analysis.
To put it politely I don't think you've looked at the code and output in
enough detail.
Ignore the first 'trace' line - it just happens to be there.
The substantive issue - LINENO going backwards - occurs across four source
lines, two of which are blank, and in which the only 'active ingredient' is
a 'fi'
So unless the function calls are managing some 'delayed action' I can't
see how they can be involved.
I suspect that if I work hard I can get the example down to one empty line,
but I'll need to put money where mouth is on that.
I will put some effort into minimising the content of an example - but
starting with 2800 lines that could be much effort.
Thanks
David
On Wed, Sep 1, 2021 at 6:09 PM Greg Wooledge wrote:
> On Wed, Sep 01, 2021 at 04:52:29PM +0100, David Collier wrote:
> > greg - I'm sorry - I assume there is a proper place for me to post
> > follow-up info, can you let me know where it is?
>
> On the bug-bash mailing list is fine. If the script is too big to
> post on bug-bash, then it's not useful for debugging anyway. We'd
> need something smaller that we can actually wrap our heads around.
>
> > I could try for a short script, but this thing is a bit like herding
> eels.
> > I narrowed it down to a single line containing 'sync' - but as you say
> > that's clearly impossible.
> > And to my embarrassment the bug remains unchanged when I comment-out
> > the word sync.
>
> OK, good, that's what I would expect.
>
> > !!!Here is a code segment ( I have removed a few == signs so
> it
> > fits across my screen. ):
> >
> > echo " At this point \$LINENO has correctly counted about
> > 2800 lines=test @ 2838 $LINENO"
> > echo "=== Something makes bash lose a few counts from \$LINENO - in this
> > case about nine - no idea how to fix it. ==="
> >
> > if ! filesOrSubdirsPresent "${rootOfDummyFsToInstallAPADN}/usr/sbin/*"
> > then :
> > if ${G_verbose} ; then echo "Skipping ${targetAPARN} - nothing
> found";
> > fi
> > else :
> > echo "Installing: ${targetAPARN}*"
> >
> > # Do we really want the '-p' option here??? - it corrupts ownership
> of
> > directories!
> > ( cp -dpR "${rootOfDummyFsToInstallAPADN}"/usr/sbin/* ${cpDestFlag}
> > "${targetAPARN}" )
> >
> > # Not sure we can know that there are no .sh or .pl scripts already
> > there but with execute off.
> > # but we install so many we can't go round naming them one-by-one.
> > #
> > setExecutabilityOfScriptsInEntireBranch "${targetAPARN}" # All of
> > our scripts in /usr/sbin do have .sh extensions.
> > echo
> >
> "===test
> > @ +16 $LINENO"
> > sync
> >
> > fi
> > echo
> >
> "==test
> > @ +20 $LINENO"
>
> I'm guessing filesOrSubdirsPresent and
> setExecutabilityOfScriptsInEntireBranch are functions.
>
> > As you can see, four lines further on, and LINENO has gone down by 5 -
> > making it 9 too small
>
> My first guess is that it has something to do with those function calls.
> Either the fact that bash is calling a function *at all*, or something
> that happens specifically in one of those functions, might be throwing
> off the count.
>
> IIRC you said you were using bash 5.0, so here's a dumb little test with
> bash-5.0 on my system:
>
>
> unicorn:~$ cat foo
> #!/usr/local/bin/bash-5.0
>
> f() {
> : this is f
> }
>
> echo "Point A: line #$LINENO"
> f
> echo "Point B: line #$LINENO"
> unicorn:~$ ./foo
> Point A: line #7
> Point B: line #9
>
>
> This one passes the test, so it's probably not something like "all
> functions break LINENO in the caller in bash 5.0". That would have been
> too obvious.
>
> You should look at setExecutabilityOfScriptsInEntireBranch (since that's
> the last function call before the problem is observed). Maybe something
> funny happens in there. You might be able to comment out that function
> call and see if that makes the problem vanish. If it does, then you can
> try to pinpoint what part of the function is triggering the problem.
>
> If it doesn't, then I'm at a loss.
>
Re: help adding some features to 5.1
Just for me :) I know my productivity will be higher. Eventually I'll do a YouTube video on it. If we see enough adoption, we can consider rolling them in. !$ picking up & from the previous command really is a no no :) On Wed, Sep 1, 2021 at 6:36 PM Lawrence Velázquez wrote: > On Wed, Sep 1, 2021, at 8:20 PM, Ananth Chellappa wrote: > > I hope I can make a genuine contribution at some point. > > If you're hoping/planning on getting these changes accepted into > bash, it might be worth hashing out details with Chet before expending > your time and energy. (I am not a contributor, nor do I have any > formal affiliation with the project. I just write email.) > > On the other hand, if this is for yourself, then hack away! > > -- > vq >
