Help! bash annoyingly kills background processes when xterm is closed
Douglas Alan
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
rocky
ignored so that command can continue after you log out... here is the
command for your need
nohup xemacs &
Douglas Alan
> nohup xemacs &
(1) Although this works for Linux, it doesn't work for OS X, which is
what I am now using these days. I don't know whether or not the
issue extends to other BSD-based Unixes.
(2) Even if it did work, which it doesn't, I don't want to have to
type "nohup" all of the time. Though perhaps I could define "x" to
be an alias that will do both the "nohup" and the "&" so that I
could do:
$ x xemacs
Alas, I don't know bash well enough yet to know if it is possible
to define such an alias. I could certainly write a little shell
script called "x" that would do the job, but I don't want to lose
job control over xemacs, et. al., so a script here wouldn't really
cut the muster.
|>oug
Stein Arne Storslett
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.
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.
If you want xemacs to stay up use nohup, or better, start it from your
window manager.
--
Stein Arne
Douglas Alan
> 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
Alan Connor
>
> bash$ bash -c "emacs &"
>
Write an alias or function for that?
> 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!
>
Right on. I use a minimal X-window manager (flwm) with a minimal
x-terminal-emulator (aterm) that come up on login, then run
screen manually for my real window manager.
(if I bring it up tied to the x-term as a -e argument in my
~/.Xsession, then I can't detach the screen session and logout
without everything screwing up, which sounds pretty similar to
your challenge here.)
Screen runs fine in an x-term without the X-window manager,
but then when I call an X-app (rarely), it takes over the
terminal. The whole point is to be able to run X-apps AND screen
simultaneously, cutting & pasting between the two as needed.
AC
Douglas Alan
>> bash$ bash -c "emacs &"
> 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
Alan Connor
Alan" wrote:
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?
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.
comp.emacs.xemacs
gnu.emacs.help
comp.emacs
And if you can't find your answer on those groups:
alt.religion.emacs
Pray!
:-)
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.
Is there really still an editor hidden in there someplace?
:-)
AC
Mike Castle
Douglas Alan <nes...@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
Martijn Lievaart
> 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.
It's bash alright. On SIGHUP, the signal is propagated to all children,
except children that are `disown`ed.
M4
--
Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering
their time inventing and implementing new, exciting ways for software
to suck. -- Toni Lassila in the Monastry
Alan Connor
Lievaart" wrote:
> On Sat, 14 May 2005 07:25:56 +0000, Alan Connor wrote:
>
>> 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.
>
> It's bash alright. On SIGHUP, the signal is propagated to all
> children, except children that are `disown`ed.
But it's emacs' inabilitity to deal with bash as it is that
is REALLY the problem.
No one is expected to patch their shell to accomodate every
oddball application that comes along. It's the responsibility
of the oddball application's creators and maintainers to make
sure that it will work with the standard software found in the
environments that it will be employed in.
The fact that emacs performs well with tcsh and poorly with bash
is just ridiculous: bash is the default shell that on every major
linux distro and most of the minor ones. I've never seen a distro
that comes with tcsh as its default shell. Bash _is_ the GNU
shell.
>
> M4
> --
> Ah, the beauty of OSS. Hundreds of volunteers worldwide
> volunteering their time inventing and implementing new,
> exciting ways for software to suck. -- Toni Lassila in the
> Monastry
>
I've been meaning to tell you for a long time, Martijn, that that
is a very funny sig.
Don't know OSS at all, but it doesn't look very promising :-)
AC
Martijn Lievaart
> 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.
tcsh:
The shell exits on a hangup (see also the logout shell variable).
By default, the shell's children do too, but the shell does not
send them a hangup when it exits. hup arranges for the shell to
send a hangup to a child when it exits, and nohup sets a child to
ignore hangups.
bash:
The shell exits by default upon receipt of a `SIGHUP'. Before
exiting, an interactive shell resends the `SIGHUP' to all jobs, running or
stopped. Stopped jobs are sent `SIGCONT' to ensure that they receive the
`SIGHUP'. 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.
Martijn Lievaart
>> It's bash alright. On SIGHUP, the signal is propagated to all
>> children, except children that are `disown`ed.
>
> But it's emacs' inabilitity to deal with bash as it is that
> is REALLY the problem.
No, all X apps I tried exhibit this behaviour, not just emacs.
> No one is expected to patch their shell to accomodate every
> oddball application that comes along. It's the responsibility
But for ALL applications?
> of the oddball application's creators and maintainers to make
> sure that it will work with the standard software found in the
> environments that it will be employed in.
>
> The fact that emacs performs well with tcsh and poorly with bash
> is just ridiculous: bash is the default shell that on every major
> linux distro and most of the minor ones. I've never seen a distro
> that comes with tcsh as its default shell. Bash _is_ the GNU
> shell.
Bash is a much better shell as well (than tcsh, imnsho, etc). However,
it looks like this behaviour has been the default with bash (the sighup
behaviour is noted as a difference from the bourne shell), so it's more of
a basic incompatibility of bash and X apps.
> Don't know OSS at all, but it doesn't look very promising :-)
Ah, just watch out for those projects with top programmers but crappy
engineers on top :-)
Alan Connor
<snip>
> so it's more of a basic incompatibility of bash and X apps.
<rather than a problem with emacs>
That's actually an important insight. If there's one major
incompatibility, there are probably others, which could
explain why myself and others have always found X to be a
pain-in-the-ass.
And X was around before bash. I had it backwards.
(Truthfully, I could live without X. Really just need the
abilitity to display graphics. Don't need a GUI at all, much
less the ability to run remote GUIs.)
>
>> Don't know OSS at all, but it doesn't look very promising :-)
>
> Ah, just watch out for those projects with top programmers but
> crappy engineers on top :-)
Well, it _could_ be worse: There could be bean-counters
running the engineers, like it is in the windoze world.
AC
Bill Marcum
>
> 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.
>
( xemacs & )
--
Test-tube babies shouldn't throw stones.
Stephane CHAZELAS
> 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.
Except that what xemacs will write to the terminal will be lost
(every write will end up in a I/O error).
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).
>
> 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.
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).
zsh is even more consistent as it also hups its children when
you exit (even though it asks for your confirmation to exit if
there are background jobs). You could have add the same behavior
with bash with shopt -s huponexit, though. But it seems that it
doesn't work at least with bash 3.0.16
> Also, I know that I can "disown" the xemacs in bash before killing the
> xterm, and this will prevent the xemacs from being killed.
That makes sense as well. If you didn't start xemacs with nohup,
then you want it to belong to that terminal and shell session.
> 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.
[...]
trap exit HUP
seems to work.
The question I'd ask is why having switched from tcsh to bash?
zsh would have been a much more straightforward choice.
To get the behavior you want with zsh:
unsetopt hup checkjobs
--
Stéphane
Douglas Alan
> Douglas Alan <nes...@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
It's value is "off", but changing it's value to "on" has no effect
either way.
|>oug
Douglas Alan
> 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-13, 02:12(-04), Douglas Alan:
>> 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.
> 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.
>> 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.
> 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
>> 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.
> 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
Alan Connor
Alan" wrote:
Very useful thread, Doug. Thanks for persisting. I've saved
it in my X docs.
AC
Alan Connor
Alan" wrote:
> Alan Connor <zzz...@xxx.yyy> writes:
>
>>> 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.
>
>> 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.
Yes it does. It's the same thing as doing: <command> &.
You are putting a running process in the background to
free up the terminal/pseudo-terminal (keyboard/mouse and
screen) for other uses.
Just GUI style rather than CLI style.
> 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.
>
That's just one part of it. One (obviously) doesn't always want
background jobs to be suspended. I suggest that you read Chapter
8 "Process Handling", in "Learning the bash Shell" 2nd Edition,
OREILLY.
<snip>
AC
Douglas Alan
>>> 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.
> 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.
>> 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.
> 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
Alan Connor
Alan" wrote:
> Alan Connor <zzz...@xxx.yyy> writes:
>
>>>> 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.
>
>> 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.
Not in functionality.
Which is what I'm concerned with.
Fortunately, there's usually more than one way to
skin a cat, and I don't let fatheaded geeks confuse me.
>
>>> 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.
>
>> 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.
Sure. That's why you started this thread. Because you know
all about shell job control.
_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.
And I hope it is obvious to you now that is IS emacs that is
the source of your problem. 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.
AC
Eric Moors
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.
Eric
Alan Connor
<205bf$4289992a$c2abfc64$16...@news1.tudelft.nl>, "Eric
Moors" wrote:
<snip>
> 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 brought up screen earlier, and he utterly ignored the
suggestion.
But I run screen in an xterm and don't know how you
could expect to run an X app within screen running
in a plain tty.
Be interested in hearing what you have to say about
this.
Am I missing something?
AC
Eric Moors
> On comp.unix.shell, in
> <205bf$4289992a$c2abfc64$16...@news1.tudelft.nl>, "Eric
> Moors" wrote:
>
> <snip>
>
>> 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 brought up screen earlier, and he utterly ignored the
> suggestion.
>
> But I run screen in an xterm and don't know how you
> could expect to run an X app within screen running
> in a plain tty.
I am working in X, as is the OP I think.
Anyway xemacs is not an X application and runs perfectly
well in a plain tty. run it as xemacs -nw to prevent it
from using a new window.
Eric
Alan Connor
>
>
> Alan Connor wrote:
>
>> On comp.unix.shell, in
>> <205bf$4289992a$c2abfc64$16...@news1.tudelft.nl>, "Eric
>> Moors" wrote:
>>
>> <snip>
>>
>>> 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 brought up screen earlier, and he utterly ignored the
>> suggestion.
>>
>> But I run screen in an xterm and don't know how you
>> could expect to run an X app within screen running
>> in a plain tty.
>
> I am working in X,
Okay.
> as is the OP I think.
Yes.
> Anyway xemacs is not an X application and runs perfectly
> well in a plain tty. run it as xemacs -nw to prevent it
> from using a new window.
How could it use a new window if it wasn't running in
X?
And it depends on the xlibs. Do you mean that it doesn't need
an xserver?
AND why would anyone call an application "x*" if it wasn't an X
application?!
AC
Martijn Lievaart
> _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.
>
> And I hope it is obvious to you now that is IS emacs that is
> the source of your problem. 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.
Funny. You must be using a different bash and X apps than the rest of us.
Two people have by now confirmed the behaviour the OP is seeing and we now
know for sure it is caused by different handling of SIGHUP by tcsh and
bash. I don't see how you can say the problem is with emacs (btw, the OP
uses xemacs, not emacs).
Eric Moors
>> well in a plain tty. run it as xemacs -nw to prevent it
>> from using a new window.
>
> How could it use a new window if it wasn't running in
> X?
Well, it can do both.
running in X using a new window, as well as running inside
the current console.
> And it depends on the xlibs. Do you mean that it doesn't need
> an xserver?
yep.
Eric
Alan Connor
Lievaart" wrote:
> On Tue, 17 May 2005 00:45:46 +0000, Alan Connor wrote:
>
>> _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.
>>
>> And I hope it is obvious to you now that is IS emacs that is
>> the source of your problem. 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.
>
> Funny. You must be using a different bash and X apps than the
> rest of us. Two people have by now confirmed the behaviour the
> OP is seeing and we now know for sure it is caused by different
> handling of SIGHUP by tcsh and bash. I don't see how you can
> say the problem is with emacs (btw, the OP uses xemacs, not
> emacs).
>
Well gee: I use X apps and job control in bash EVERY FUCKING DAY
and don't have any problems at all.
(I don't use a Graphical Integrated Desktop Environment like
Gnome or KDE. Just the command line. I rarely touch a mouse.)
But I don't use xemacs.
Tell me: If you have 2 rocks in one hand, and 2 rocks
in the other, and you put the ones in your right hand
in your left hand, how many rocks are now in your left
hand?
Take your time.
AC
Glyn Millington
> Well gee: I use X apps and job control in bash EVERY FUCKING 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
Martijn Lievaart
>> Funny. You must be using a different bash and X apps than the
>> rest of us. Two people have by now confirmed the behaviour the
>> OP is seeing and we now know for sure it is caused by different
>> handling of SIGHUP by tcsh and bash. I don't see how you can
>> say the problem is with emacs (btw, the OP uses xemacs, not
>> emacs).
>>
>
> Well gee: I use X apps and job control in bash EVERY FUCKING DAY
> and don't have any problems at all.
I don't have a problem with the way bash behaves as well. For the OP, for
me and some other poster, it behaves consistently, whether the X app is
emacs, xemacs or some other X app. If you don't get the same behaviour,
you must be using a different bash than we are.
> Tell me: If you have 2 rocks in one hand, and 2 rocks
> in the other, and you put the ones in your right hand
> in your left hand, how many rocks are now in your left
> hand?
Tell me, what has it to do with the OPs problem? Ah, you mean it's simple
logic? Well, me thinks me right, you wrong, see above. If you think
differently, would you be so kind to give some argument why? Instead of
the vagueries you have been giving here?
Alan Connor
Lievaart" wrote:
> On Tue, 17 May 2005 10:52:41 +0000, Alan Connor wrote:
>
>>> Funny. You must be using a different bash and X apps than the
>>> rest of us. Two people have by now confirmed the behaviour
>>> the OP is seeing and we now know for sure it is caused by
>>> different handling of SIGHUP by tcsh and bash. I don't see
>>> how you can say the problem is with emacs (btw, the OP uses
>>> xemacs, not emacs).
>>
>>
>> Well gee: I use X apps and job control in bash EVERY FUCKING
>> DAY and don't have any problems at all.
>
> I don't have a problem with the way bash behaves as well. For
> the OP, for me and some other poster, it behaves consistently,
> whether the X app is emacs, xemacs or some other X app. If you
> don't get the same behaviour, you must be using a different
> bash than we are.
>
>> Tell me: If you have 2 rocks in one hand, and 2 rocks in the
>> other, and you put the ones in your right hand in your left
>> hand, how many rocks are now in your left hand?
>
> Tell me, what has it to do with the OPs problem? Ah, you mean
> it's simple logic? Well, me thinks me right, you wrong, see
> above. If you think differently, would you be so kind to give
> some argument why? Instead of the vagueries you have been
> giving here?
>
Seems to me that if you really thought you were right, then
you would post the version of bash you are using.
It is YOU, therefore, that is being "vague".
(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.)
AC
--
alanconnor AT earthlink DOT net
Use your real return address or I'll never know you
even tried to mail me. http://tinyurl.com/2t5kp
~
Alan Connor
It's pretty clear that we are dealing here with a couple
of folks whose home group is alt.religion.emacs.
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 :-)
The date header on that post can be used to verify the
fact that I haven't simply _said_ that I was using the
same version of bash that they are.
So light a couple of incense sticks on your altar to the Great
God Emacs, guys, and post your bash version info!
:-)
AC
Glyn Millington
> (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
> 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
>> 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.
> 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 geeks 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
> 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
Alan Connor
Alan" wrote:
> Alan Connor <zzz...@xxx.yyy> writes:
>
>>> 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.
Not really, actually. A stack of processes is a stack of
processes.
>
>> 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.
And I'm interested in intelligent conversations, not sparring
with bitchy and conceited geeks.
Go away. The rest of this post and all of your other post
have been deleted un-read.
Never met an emacs user yet that wasn't a stuck-up prick.
Fortunately, there are VERY few of them.
PLONK
<snip>
AC
Douglas Alan
> And I'm interested in intelligent conversations, not sparring
> with bitchy and conceited geeks.
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