Home > Archive > Unix Shell Programming > November 2006 > Help! bash annoyingly kills background processes when xterm is
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help! bash annoyingly kills background processes when xterm is
|
|
| Douglas Alan 2005-05-13, 4:09 pm |
| I've been using tcsh for quite a few years and I want to switch to
bash, but I'm having a serious usability problem with bash that is
preventing me from doing so. I'll illustrate the problem with an
example:
Let's say I have an xterm, and in the xterm I have a tcsh running.
Now let's say from the tcsh, I fire up an xemacs in the background,
like so:
% xemacs &
Now let's say I kill the xterm by clicking on its close icon. The
xemacs continues running and everything is fine, as far as I'm
concerned.
Now let's say that I do all of the above all over again, only I use
bash instead of tcsh. This time, when I kill the xterm by clicking on
its close icon, the xemacs is killed too. This is doubleplus ungood!
Strangely, if I kill the xterm by typing "exit" to bash, instead of
clicking on the xterm's close icon, then the xemacs is not killed.
Also, I know that I can "disown" the xemacs in bash before killing the
xterm, and this will prevent the xemacs from being killed.
Neither of these solutions is what I want, however. I need bash to
behave as tcsh does in this regard.
Is there some bash option of which I am unaware to make it do the
"right thing" here? I sure hope so, or I fear that I will be stuck
with tcsh forever.
|>oug
| |
| Douglas Alan 2005-05-14, 4:05 pm |
| Stein Arne Storslett <sastorsl@THOU.SHALT.NOT.SPAM.broadpark.no> writes:
> AFAIK, what you are experiencing is the correct behaviour. Why xemacs
> stays up if you type exit instead of just closing the windows I can't
> understand.
What I am experiencing is NOT the correct behavior. The fact that
csh has behaved the way I expect for the past 25 years and that bash
behaves the way I expect on "exit" show pretty clearly what the
correct behavior is.
What bash is doing wrong is responding incorrectly to being cruelly
terminated by xterm, rather than being nicely terminated with an
"exit" command. This incorrect response should be fixed.
> The behaviour of a good shell is to kill it's "children" (xemacs being
> the child of the bash process in you xterm) when it dies.
That hasn't been true since the Bourne shell stopped being the
standard user interface more than 20 years ago. Since then,
backgrounded processes have been allowed to run on their own,
independent from the invoking shell (modulo job control).
> If you want xemacs to stay up use nohup
As I already pointed out, this doesn't work under OS X. (And perhaps
under BSD in general?)
What does work fine is
bash$ bash -c "emacs &"
If nothing else, That ought to show you that what I'm saying is correct.
> or better, start it from your window manager.
I don't want to use a @%$!@$@# GUI. I want to use a command line
shell to invoke my programs, thank you!
|>oug
| |
| Douglas Alan 2005-05-14, 4:05 pm |
| Alan Connor <zzzzzz@xxx.yyy> writes:
[color=darkred]
> Write an alias or function for that?
Well, yes, I mentioned earlier that I can do that, but then I lose job
control on X programs. I'd rather stick with the tcsh than lose job
control.
|>oug
| |
| Mike Castle 2005-05-14, 4:05 pm |
| In article <lc64xnmz7e.fsf@gaffa.mit.edu>,
Douglas Alan <nessus@mit.edu> wrote:
>Is there some bash option of which I am unaware to make it do the
>"right thing" here? I sure hope so, or I fear that I will be stuck
>with tcsh forever.
In bash, what is the output of:
shopt huponexit
| |
| Douglas Alan 2005-05-16, 3:58 am |
| dalgoda@ix.netcom.com (Mike Castle) writes:
> Douglas Alan <nessus@mit.edu> wrote:
[color=darkred]
> In bash, what is the output of:
> shopt huponexit
It's value is "off", but changing it's value to "on" has no effect
either way.
|>oug
| |
| Douglas Alan 2005-05-16, 3:58 am |
| Martijn Lievaart <m@remove.this.part.rtij.nl> writes:
> To prevent the shell from sending the `SIGHUP' signal to a
> particular job, it should be removed from the jobs table with the `disown'
> builtin (*note Job Control Builtins::) or marked to not receive `SIGHUP'
> using `disown -h'.
> I'm not aware of a way to make bash change it's behaviour on this.
Well, actually, you've pointed out the answer. "disown -h" is the way
to make X programs work the way they should, without losing job
control. (I knew about "disown", but I didn't know about "disown
-h".)
So, what I have to do is make an alias called "x" or something so that
when I do
$ x emacs
it will expand to
$ emacs &; disown -h
Why they have to make it so difficult, though, I can't fathom. It
just doesn't make any sense for background processes to be treated
differently on normal exit from the shell than on abnormal
terminations of the shell.
|>oug
| |
| Douglas Alan 2005-05-16, 3:58 am |
| Stephane CHAZELAS <this.address@is.invalid> writes:
> 2005-05-13, 02:12(-04), Douglas Alan:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> Except that what xemacs will write to the terminal will be lost
> (every write will end up in a I/O error).
I don't think that's true (that every write to the terminal ends up
with an I/O error). I think with the csh, it just gets redirected to
/dev/null.
> Also, you lose a pseudo-terminal, as the one from which you
> started xemacs won't be reused as long as you don't exit emacs
> (at least on Linux).
There must be a lot of pseudo-terminals, then, as I've never seen this
to cause any problem.
[color=darkred]
> That makes sense, if the terminal is disconnected, you don't
> want applications to hang around as they would be out of control
> (if you keep in mind that a shell doesn't know that its children
> might have a connection to a xserver that provides with another
> mean to control them).
In 20 years of using X with the tcsh, I have never once seen a problem
caused by the way that it does things. And it behaves, in this one
regard, intuitively, while bash does not.
Also, I don't see a distinction in programs being "out of control" on
typing exit, versus on clicking the close box on the terminal. Both
cause the xterm to go away, and to most people, the two ways of
closing the terminal would be though of as synonymous.
> The question I'd ask is why having switched from tcsh to bash?
> zsh would have been a much more straightforward choice.
Because I want to use a shell that is on every machine that I might
use, and the tcsh and bash have become universal standards.
|>oug
| |
| Douglas Alan 2005-05-16, 3:58 am |
| Alan Connor <zzzzzz@xxx.yyy> writes:
[color=darkred]
> Job control on X apps? I just use Alt-Tab to put the
> windows in the background/foreground. Why would you
> need any other sort of job control?
Alt-Tab has nothing to do with job control. Job control allows you to
easily stop processes for a while, for instance, so that they don't
eat up CPU while you are trying to do something else, and then allows
you to easily restart the processes later, etc.
> Obviously, I don't know emacs at all, (nor do most
> unix/linux people, actually) and it's probably emacs
> that is the source of your difficulties, not bash.
Emacs has nothing to do with the issue. I was just using Emacs as an
example. The issue exist for any X program.
> Frankly, I'm not surprised that emacs works better with tcsh
> than bash. It just seems to fit. Why tailor it to work with
> the GNU shell, after all. Makes too much sense.
I think now that you're typing at the computer with too little sleep.
|>oug
| |
| Douglas Alan 2005-05-16, 8:58 pm |
| Alan Connor <zzzzzz@xxx.yyy> writes:
[color=darkred]
[color=darkred]
> Yes it does. It's the same thing as doing: <command> &.
No, it does not. Alt-Tab (in, e.g., Gnome) merely brings windows (not
even entire programs, but just individual windows) to the foreground,
and perhaps deiconfies them. It has nothing to do with shell "job
control".
> You are putting a running process in the background to
> free up the terminal/pseudo-terminal (keyboard/mouse and
> screen) for other uses.
Putting a process in a shell's background is completely and utterly
different from pushing a window to the bottom of the window stack or
iconifying them. They are completely different things.
> Just GUI style rather than CLI style.
That's a world of difference.
[color=darkred]
> That's just one part of it.
That's why I said, "for instance".
> One (obviously) doesn't always want background jobs to be suspended.
Yes, of course.
> I suggest that you read Chapter 8 "Process Handling", in "Learning
> the bash Shell" 2nd Edition, OREILLY.
Whatever. I know all about shell job control -- I've been using it
for 25 years, and I know what it should and shouldn't do.
|>oug
| |
| Glyn Millington 2005-05-17, 3:59 pm |
| Alan Connor <zzzzzz@xxx.yyy> writes:
> Well gee: I use X apps and job control in bash EVERY XXXXING DAY
so far so good.
> and don't have any problems at all.
Ah, but here, Alan my boy, the evidence is against you.
Love and hugs
Glyn
| |
| Douglas Alan 2005-05-18, 4:01 am |
| dalgoda@ix.netcom.com (Mike Castle) writes:
> Douglas Alan <nessus@mit.edu> wrote:
[color=darkred]
> In bash, what is the output of:
> shopt huponexit
It's value is "off", but changing it's value to "on" has no effect
either way.
|>oug
| |
| Douglas Alan 2005-05-18, 4:01 am |
| Alan Connor <zzzzzz@xxx.yyy> writes:
[color=darkred]
> Job control on X apps? I just use Alt-Tab to put the
> windows in the background/foreground. Why would you
> need any other sort of job control?
Alt-Tab has nothing to do with job control. Job control allows you to
easily stop processes for a while, for instance, so that they don't
eat up CPU while you are trying to do something else, and then allows
you to easily restart the processes later, etc.
> Obviously, I don't know emacs at all, (nor do most
> unix/linux people, actually) and it's probably emacs
> that is the source of your difficulties, not bash.
Emacs has nothing to do with the issue. I was just using Emacs as an
example. The issue exist for any X program.
> Frankly, I'm not surprised that emacs works better with tcsh
> than bash. It just seems to fit. Why tailor it to work with
> the GNU shell, after all. Makes too much sense.
I think now that you're typing at the computer with too little sleep.
|>oug
| |
| Douglas Alan 2005-05-18, 4:01 am |
| Stephane CHAZELAS <this.address@is.invalid> writes:
> 2005-05-13, 02:12(-04), Douglas Alan:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> Except that what xemacs will write to the terminal will be lost
> (every write will end up in a I/O error).
I don't think that's true (that every write to the terminal ends up
with an I/O error). I think with the csh, it just gets redirected to
/dev/null.
> Also, you lose a pseudo-terminal, as the one from which you
> started xemacs won't be reused as long as you don't exit emacs
> (at least on Linux).
There must be a lot of pseudo-terminals, then, as I've never seen this
to cause any problem.
[color=darkred]
> That makes sense, if the terminal is disconnected, you don't
> want applications to hang around as they would be out of control
> (if you keep in mind that a shell doesn't know that its children
> might have a connection to a xserver that provides with another
> mean to control them).
In 20 years of using X with the tcsh, I have never once seen a problem
caused by the way that it does things. And it behaves, in this one
regard, intuitively, while bash does not.
Also, I don't see a distinction in programs being "out of control" on
typing exit, versus on clicking the close box on the terminal. Both
cause the xterm to go away, and to most people, the two ways of
closing the terminal would be though of as synonymous.
> The question I'd ask is why having switched from tcsh to bash?
> zsh would have been a much more straightforward choice.
Because I want to use a shell that is on every machine that I might
use, and the tcsh and bash have become universal standards.
|>oug
| |
| Glyn Millington 2005-05-18, 8:57 am |
| Alan Connor <zzzzzz@xxx.yyy> writes:
> (I've ignored "Glyn Millington's" post because that's a
> sockpuppet of a stupid troll that always yapping at my
> heels because it hates Challenge-Response mail filters.)
Delusional!! Completely bonkers!!
Exactly who is hiding? Email me, you get the real thing. No munged
headers in _my_ posts :-) Why do you need that if your system is so
great?
Mark you, I do dislike your habit of spamming with that ridiculous C-R
system.
Trouble is, you can't resist the Challenge of Responding _somehow_ can
you, Al my boy. But for all your hard words I remain your greatest fan
:-)
Love and hugs
Glyn
| |
| Glyn Millington 2005-05-18, 8:57 am |
| Alan Connor <zzzzzz@xxx.yyy> writes:
> But just in case they are actually willing to come out of
> the closet, I've posted my version of bash on a dead newsgroup.
>
> The --version string has been run through sed, using
> the transform command, to substitute various characters
> for random ones, and will have to be deciphered with
> the inversion of that sed script, which I will supply,
> and the article has been posted under an alias to keep
> it from being located: You know how these religious
> fanatics are :-)
A couple of people have a problem with bash - emacs is given simply as an
example. It is a problem with most if not all X apps. This has been
clearly stated, several times. I have no reason to doubt the honesty of
those making that statement.
You, having leapt to an idiotic conclusion, cannot bear to be wrong can you
Alan? It must be Emacs, it cannot be bash or the way it is configured. So
you expect the rest of us to to through the above farce just to find out
what your version of bash is?
This is the behaviour of a sane man?
Glyn
| |
| Douglas Alan 2005-05-18, 8:58 pm |
| Alan Connor <zzzzzz@xxx.yyy> writes:
[color=darkred]
[color=darkred]
> Yes it does. It's the same thing as doing: <command> &.
No, it does not. Alt-Tab (in, e.g., Gnome) merely brings windows (not
even entire programs, but just individual windows) to the foreground,
and perhaps deiconfies them. It has nothing to do with shell "job
control".
> You are putting a running process in the background to
> free up the terminal/pseudo-terminal (keyboard/mouse and
> screen) for other uses.
Putting a process in a shell's background is completely and utterly
different from pushing a window to the bottom of the window stack or
iconifying them. They are completely different things.
> Just GUI style rather than CLI style.
That's a world of difference.
[color=darkred]
> That's just one part of it.
That's why I said, "for instance".
> One (obviously) doesn't always want background jobs to be suspended.
Yes, of course.
> I suggest that you read Chapter 8 "Process Handling", in "Learning
> the bash Shell" 2nd Edition, OREILLY.
Whatever. I know all about shell job control -- I've been using it
for 25 years, and I know what it should and shouldn't do.
|>oug
| |
| Douglas Alan 2005-05-20, 3:57 pm |
| Stein Arne Storslett <sastorsl@THOU.SHALT.NOT.SPAM.broadpark.no> writes:
> AFAIK, what you are experiencing is the correct behaviour. Why xemacs
> stays up if you type exit instead of just closing the windows I can't
> understand.
What I am experiencing is NOT the correct behavior. The fact that
csh has behaved the way I expect for the past 25 years and that bash
behaves the way I expect on "exit" show pretty clearly what the
correct behavior is.
What bash is doing wrong is responding incorrectly to being cruelly
terminated by xterm, rather than being nicely terminated with an
"exit" command. This incorrect response should be fixed.
> The behaviour of a good shell is to kill it's "children" (xemacs being
> the child of the bash process in you xterm) when it dies.
That hasn't been true since the Bourne shell stopped being the
standard user interface more than 20 years ago. Since then,
backgrounded processes have been allowed to run on their own,
independent from the invoking shell (modulo job control).
> If you want xemacs to stay up use nohup
As I already pointed out, this doesn't work under OS X. (And perhaps
under BSD in general?)
What does work fine is
bash$ bash -c "emacs &"
If nothing else, That ought to show you that what I'm saying is correct.
> or better, start it from your window manager.
I don't want to use a @%$!@$@# GUI. I want to use a command line
shell to invoke my programs, thank you!
|>oug
| |
| Glyn Millington 2005-05-20, 3:57 pm |
| Alan Connor <zzzzzz@xxx.yyy> writes:
> Well gee: I use X apps and job control in bash EVERY XXXXING DAY
so far so good.
> and don't have any problems at all.
Ah, but here, Alan my boy, the evidence is against you.
Love and hugs
Glyn
| |
| Douglas Alan 2005-05-20, 8:57 pm |
| Alan Connor <zzzzzz@xxx.yyy> writes:
[color=darkred]
[color=darkred]
[color=darkred]
> Not in functionality.
> Which is what I'm concerned with.
You chose to answer a completely different question than the one I
asked, and then claim that as an answer. Mabye that's good enough for
you, but it's not good enough for me. I'm interested in the answer to
THE QUESTION I ASKED, not to the question that YOU THINK I should be
interested in.
> Fortunately, there's usually more than one way to skin a cat, and I
> don't let fatheaded g s confuse me.
If you aren't interested in answering the question, then that's fine
with me, but just do everyone a favor, then, and stay out of the fray.
> _I'm_ not the one that had a problem with bash job control.
> I run X apps from the commandline in bash all of the time
> without any problems. Using job control.
Well, then perhaps your implementation of bash behaves differently
from mine. Mine exhibits the symptoms that I have complained about,
and I assert that the behavior is incorrect.
> And I hope it is obvious to you now that is IS emacs that is
> the source of your problem.
Let me repeat for the nth time: THE PROBLEM HAS NOTHING TO DO WITH
EMACS. THE PROBLEM OCCURS WITH EVERY SINGLE X PROGRAM I HAVE TRIED
(except for xterm, which seems to insulate itself from the problem.)
Is that clear enough for you?
> I have no problems with using
> job control on X apps with bash at all and don't require
> any special shell opts to deal with them.
Well, I wish that I had your implementation of bash, then.
Unfortunately, I don't. But I see the problem under Red Hat
Linux 9.0, OS X 10.3, and Solaris 9.
|>oug
| |
| Douglas Alan 2005-05-20, 8:57 pm |
| Eric Moors <scare.crow@oz.land> writes:
> Just another idea that might be of interest here: screen
> start a screen session : screen
> start xemacs from it : xemacs
> detach from the session: ctrl<a>-d
> reattach for jobcontrol: screen -R
> Works from any shell afaik, and screen is fairly standard.
I don't even have to detach the screen for this to work. The screen
will automatically detach itself when the xterm is killed. So, I
suppose I can alias xterm to "xterm -e screen" to work around the
problem. This is certainly a reasonable suggestion, then.
I think, however, if I take this approach, I'll end up with an
ever-growing number of screen processes lying around that I never
remember to clean up, and I don't like having to type ^Aa to get a ^A
all the time....
|>oug
| |
| Douglas Alan 2005-05-21, 3:58 am |
| Alan Connor <zzzzzz@xxx.yyy> writes:
> And I'm interested in intelligent conversations, not sparring
> with bitchy and conceited gs.
Me too, but you seem incapable of intelligent conversation. I only
mentioned over and over again that the issue has nothing whatsoever to
do with Emacs in specific and applies to nearly all X programs--that I
was only using Emacs as an example--and yet you continue to blame the
problem on Emacs repeatedly.
You also insist on telling me that I don't need shell job control in a
windowed environment, despite the fact that I tell you that I do want
that, despite your assertions about what you think I should want.
Neither of these tacks on your part are what I would call "being
interested in intelligent conversation". You're interested in
talking, all right, but you have no interest in actually listening.
> Go away. The rest of this post and all of your other post
> have been deleted un-read.
That's excellent. Then I won't have to read anymore half-baked
replies from you.
> Never met an emacs user yet that wasn't a stuck-up prick.
That's probably because you've shown all the other ones the the same
level of intelligence, listening ability, and general disdain that
you've shown me. You get back what you sow.
|>oug
| |
| Douglas Alan 2005-05-23, 3:57 am |
| Alan Connor <zzzzzz@xxx.yyy> writes:
> And I'm interested in intelligent conversations, not sparring
> with bitchy and conceited gs.
Me too, but you seem incapable of intelligent conversation. I only
mentioned over and over again that the issue has nothing whatsoever to
do with Emacs in specific and applies to nearly all X programs--that I
was only using Emacs as an example--and yet you continue to blame the
problem on Emacs repeatedly.
You also insist on telling me that I don't need shell job control in a
windowed environment, despite the fact that I tell you that I do want
that, despite your assertions about what you think I should want.
Neither of these tacks on your part are what I would call "being
interested in intelligent conversation". You're interested in
talking, all right, but you have no interest in actually listening.
> Go away. The rest of this post and all of your other post
> have been deleted un-read.
That's excellent. Then I won't have to read anymore half-baked
replies from you.
> Never met an emacs user yet that wasn't a stuck-up prick.
That's probably because you've shown all the other ones the the same
level of intelligence, listening ability, and general disdain that
you've shown me. You get back what you sow.
|>oug
| |
| Douglas Alan 2005-05-24, 3:59 pm |
| Eric Moors <scare.crow@oz.land> writes:
> Just another idea that might be of interest here: screen
> start a screen session : screen
> start xemacs from it : xemacs
> detach from the session: ctrl<a>-d
> reattach for jobcontrol: screen -R
> Works from any shell afaik, and screen is fairly standard.
I don't even have to detach the screen for this to work. The screen
will automatically detach itself when the xterm is killed. So, I
suppose I can alias xterm to "xterm -e screen" to work around the
problem. This is certainly a reasonable suggestion, then.
I think, however, if I take this approach, I'll end up with an
ever-growing number of screen processes lying around that I never
remember to clean up, and I don't like having to type ^Aa to get a ^A
all the time....
|>oug
| |
| DrLove 2006-11-27, 9:25 pm |
| This thread is a perfect example of why, when someone asks a GOOD QUESTION... people who dont have a clue how to answer it should KEEP THEIR GODDAMN MOUTHS SHUT.
What Douglas needs to do, to get his bash shell behaving as he wants, is:
1) shopt -uq huponexit
and/or
trap "disown -a" EXIT
2) and, ALSO:
trap "disown -a" SIGHUP
Explanation:
1: unsetting huponexit will stop an interactive bash shell from deliberately telling its jobs to exit, when bash exits, ie WHEN YOU TYPE "exit" into the shell.
2: huponexit will NOT stop bash propagating signals that IT is sent, eg from window manager, to all of its jobs, so even WITH huponexit UNset (ie off), using the window manager to close a window holding a bash shell, WILL result in all jobs started by that shell also receiving the SIGHUP from the window manager. The SIGHUP will usually cause these jobs to exit (unless the jobs have been disowned, or the app does something else with the signal). And I agree with Douglas 100% that this behaviour just sucks ass.
3: But the bash trap builtin comes to the rescue.
trap "disown -a" EXIT
This command basically takes care of cases of proper exit from the shell, eg when you type exit. So this is not so necessary if you unset huponexit. But why the hell not. Handy in case your huponexit ever gets set again by accident :)
4: trap "disown -a" SIGHUP
This is the one that noone seems to realise is necessary :) It disowns all jobs when a SIGHUP signal is received. This one will prevent jobs started from bash from being SIGHUPed when you close your terminal using a window manager (which will close the terminal by sending a SIGHUP). This is the magic command which fixes most of these problems :)
Why not catch SIGTERM SIGKILL too?
Well... you could, but i think usually when you send a SIGTERM or SIGKILL to a shell, its pretty deliberate and you are generally wanting to terminate its processes too, where possible. So i wouldnt recommend trapping them.
cheerios,
John | |
| DrLove 2006-11-27, 9:33 pm |
| so, as explained in my message below, just put these 3 lines in your ~/.bashrc, and you cant go wrong:
shopt -uq huponexit
trap "disown -a" EXIT
trap "disown -a" SIGHUP
problem solved. Now you can start any application at all, from a terminal, and it wont matter if you close the terminal using "exit", or, using the window manager - all jobs started by that terminal/shell will continue happily unaffected.
If you send a SIGTERM or SIGKILL to the shell, it will propagate that on to its jobs though, unless you also trap those signals too, but I wouldnt recommend doing that. If you accidentally run a command that spawns a hundred different processes of different names, its nice to know you can SIGKILL the parent shell and easily terminate most of the sub-processes. | |
|
| What an amusing thread.
How come none of the posts by the moron are present in the thread?
anyway, to get to the point:
quote:
Originally posted by DrLove
If you send a SIGTERM or SIGKILL to the shell, it will propagate that on to its jobs though, unless you also trap those signals too, but I wouldnt recommend doing that. If you accidentally run a command that spawns a hundred different processes of different names, its nice to know you can SIGKILL the parent shell and easily terminate most of the sub-processes.
of course bash cannot trap KILL anyway,
as no process can. u should heed your own advice drlove, when speaking about KILL signals :P~
Douglas you might also be interested in
the PROMPT_COMMAND variable, which you
can use to execute a command every time that the prompt is printed.
eg you could set it to run the disown -h command.
PROMPT_COMMAND="disown -h"
or as an example of doing more than one thing:
PROMPT_COMMAND="disown -h; history -a"
of course this does not execute until
bash prints the promipt again.
as a sidenote, I used to use the 'trap' trick which drlove mentioned, however I cannot find it anywhere in my config and I definitely do not have the problem anymore. I checked using trap "echo hello" HUP and my shell is definitely getting a HUP but it does not propagate it to children.
I can't find in my config any other way that I've worked around it, so there is a chance that it is just working due to a behaviour change in newer bash version (my version is 3.00.16).
the following is off topic but as I already mentioned PROMPT_COMMAND to you, you may be interested in a way to stop separate bash sessions clobbering your bash history file.
Putting "history -a" into PROMPT_COMMAND
means that every time the prompt is printed, the shell will tack on the last command executed onto the history file.
upsides of this:
- commands you type go into your history file immediately.
- commands are in the file in the chronological order you typed them.
- command from different sessions get mixed up so you can't necessarily easily tell from your history what directory you were in when you executed some command.
downsides:
- the command doesn't get tacked onto the history file straight away if you execute a job in the foreground.
Without this option whichever shell you exit last will write the history file with just what it read from the file when it started up plus the commands you executed in that shell (which might have been none at all).
I also use shopt -s histappend but I do not think it is necessary as the use of PROMPT_COMMAND means that the shell never has any lines to write to the history when it exits anyway.
also of course you might want to set HISTSIZE and HISTFILESIZE to suitably large values.
I recommend changing HISTFILE to be different from the default, because there are various times when by accident some bash shell might get run interactively but without the history settings and will truncate the default .bash_history file to the default number of lines which is 500 or so. | |
| DrLove 2006-11-28, 5:34 pm |
| using PROMPT_COMMAND is an ugly hack :P
fair enuff re the SIGKILL not being trappable, i forgot about that, and its nice to know.
Im not convinced you dont have the problem anymore. New versions of bash will not change this behaviour...
Im using a newer version of bash than you, GNU bash, version 3.2.5(1) -[ and I still have this problem, without the trap.
I think you must be trapping SIGHUP somewhere in your config, you just cant find where you put it. :P
Thats an interesting comment about changing the HISTFILE, because it will be truncated if bash starts interactivelu without the proper HISTFILE setting. That has obviously been happening to me from time to time. Good tip. |
|
|
|
|