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
Re: help adding some features to 5.1
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
Re: help adding some features to 5.1
Thanks Sincerely Chet. I hope I can make a genuine contribution at some point. On Wed, Sep 1, 2021 at 12:27 PM Chet Ramey wrote: > On 8/31/21 6:38 PM, Ananth Chellappa wrote: > > Hi Team, > >Could I get some help locating portions of the code that would > need > > to be tweaked to add these features? > > > > If I had the time, I would love to get to know the code, but I have too > > much going on in my real job. > > > > 1. Intelligent support for !$ (and related - like !2$, !-N, etc) : This > > means - ignore the & at the end of the previous command. > > This is part of the history library: lib/readline/histexpand.c. Keep in > mind that history expansion has never worked like this, so "intelligent" > is subjective. > > > 2. Autocomplete for !$ (and related tokens) : This means - if I have > typed > > !$ and now press TAB, I want the last word from the previous command > > substituted on the command-line immediately. > > This is part of bash-specific word completion: bashline.c. > > > -- > ``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/ >
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
Re: help adding some features to 5.1
On 8/31/21 6:38 PM, Ananth Chellappa wrote: > Hi Team, > Could I get some help locating portions of the code that would need > to be tweaked to add these features? > > If I had the time, I would love to get to know the code, but I have too > much going on in my real job. > > 1. Intelligent support for !$ (and related - like !2$, !-N, etc) : This > means - ignore the & at the end of the previous command. This is part of the history library: lib/readline/histexpand.c. Keep in mind that history expansion has never worked like this, so "intelligent" is subjective. > 2. Autocomplete for !$ (and related tokens) : This means - if I have typed > !$ and now press TAB, I want the last word from the previous command > substituted on the command-line immediately. This is part of bash-specific word completion: bashline.c. -- ``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
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: LINENO is affected by sync
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?
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.
!!!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"
!!!here is the output - it is identical if I put a pound
character in front of 'sync':
= At this point $LINENO has correctly counted about
2800 lines=test @ 2838 2838
=== Something makes bash lose a few counts from $LINENO - in this case
about nine - no idea how to fix it. ===
Installing: /usr/sbin/*
===test
@ +16 2854
===test
@ +20 2849
!!!
As you can see, four lines further on, and LINENO has gone down by 5 -
making it 9 too small
I would fiddle around with line endings, but since it literally cogs
backwards I don't think it's going to be anything simple like that.
This happens again at intervals - wrong by different small numbers I think
- weirdly enough the next time it happens is also near a 'sync' operation -
which is what misled me.
Anyway - apologies for the red herring any suggestion welcome.
Do tell me if there is a proper place to put this info.
On Wed, Sep 1, 2021 at 4:01 PM Greg Wooledge wrote:
> On Wed, Sep 01, 2021 at 10:36:21AM +0100, David Collier wrote:
> > Version:
> >
> > GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf)
> >
> > Raspberry Pi using Raspbian.
> >
> > Installed from repo?
> >
> > LINENO goes backwards when run sync
> >
> > echo "== At this point \$LINENO has correctly counted
> about
> > 2800 lines=test @ 2832 $LINENO"
> > echo "=== Running 'sync' makes bash lose a few counts from \$LINENO - in
> > this case about ten - no idea how to fix it. ==="
> > sync
> > echo
> >
> "test
> > @ 2835 $LINENO"
>
> There is no plausible reason an external command (sync or any other
> external command) would be able to change the value of LINENO, which is
> an internal shell variable.
>
> Can you post a brief but complete script which demonstrates the problem?
> I suspect whatever issue you're seeing is caused by something else, not
> by the "sync" command.
>
Re: LINENO is affected by sync
On 9/1/21 5:36 AM, David Collier wrote: > Version: > > GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf) > > Raspberry Pi using Raspbian. > > Installed from repo? > > LINENO goes backwards when run sync I can't reprodude this. -- ``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
On Wed, Sep 01, 2021 at 10:36:21AM +0100, David Collier wrote: > Version: > > GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf) > > Raspberry Pi using Raspbian. > > Installed from repo? > > LINENO goes backwards when run sync > > echo "== At this point \$LINENO has correctly counted about > 2800 lines=test @ 2832 $LINENO" > echo "=== Running 'sync' makes bash lose a few counts from \$LINENO - in > this case about ten - no idea how to fix it. ===" > sync > echo > "test > @ 2835 $LINENO" There is no plausible reason an external command (sync or any other external command) would be able to change the value of LINENO, which is an internal shell variable. Can you post a brief but complete script which demonstrates the problem? I suspect whatever issue you're seeing is caused by something else, not by the "sync" command.
LINENO is affected by sync
Version: GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf) Raspberry Pi using Raspbian. Installed from repo? LINENO goes backwards when run sync echo "== At this point \$LINENO has correctly counted about 2800 lines=test @ 2832 $LINENO" echo "=== Running 'sync' makes bash lose a few counts from \$LINENO - in this case about ten - no idea how to fix it. ===" sync echo "test @ 2835 $LINENO"
Re: Squiggly heredoc - new feature request
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. -- ``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/
