After creating a shell window via M-x shell, job control
works fine in that shell (e.g. C-c C-c for intr). But
when I su, I lose job control; e.g. C-c C-c has no effect.
I'm using /bin/bash as my shell, but I get the same result
I have tried this on a number of different, but completely
stock, RedHat 6.0 installations, and the result is always
the same. I am logging in as guest, with no .bashrc or
other shell init file, and no .emacs init file, so I have
convinced myself that there is nothing wrong with my
environment. Emacs 20.3 running on my Irix box does not
have this problem.
There are many situations in which job control works just
fine in a root shell running in emacs:
- run emacs as root, M-x shell, jobcontrol is fine
- M-x rlogin; enter <system-name>; su; jobcontrol is fine
- M-x terminal-emulator; su; jobcontrol is fine
- M-x term; su; jobcontrol is fine
This is the single most annoying problem that I have with
my current RedHat systems, so I'd greatly appreciate a fix
or workaround. I've gotten and tried lots of different
advice about changing ownership and permissions on various
tty and pty files in /dev, all to no avail. I get the
feeling that there must be a simple fix, but so far I
haven't been able to find it.
I run Rawhide on one of my systems, and I just loaded
emacs-20.4.1.i386.rpm on that system. Same result, so this
problem is not fixed in emacs-20.4.
The emacs shell is not /bin/bash - it's rather an internal one that is
controlled by emacs. If you start another shell (/bin/bash) emacs
won't be able to do job controlling on that one, and the new shell
will again have issues doing job control because of emacs'
Not really a bug, just an emacs limitation.
I have a couple of "additional comments", which is not to say that I'm
complaining about the "WONTFIX" status of this bug -- in fact, I
greatly appreciate the help you've provided on this and other bugs.
I'm having trouble understanding some of the following:
> The emacs shell is not /bin/bash - it's rather an internal one that
> is controlled by emacs.
When I do M-x shell in emacs, I'm definitely getting real, live
/bin/bash -- shows up via /bin/ps and everything. I'm willing to
believe this bash is running under some other code inside emacs,
and in fact I believe the problem does have to do with the environment
in which bash (or csh) runs under emacs. But I wouldn't call this
environment a "shell" in the traditional sense -- it's certainly not
a shell process that shows up via /bin/ps.
> If you start another shell (/bin/bash) emacs won't be able to do
> job controlling on that one, and the new shell will again have
> issues doing job control because of emacs' interference.
I can certainly run another /bin/bash inside the first one under
emacs and still have job control work OK. What your comment prompted
me to discover is that when I su - <any-user> (not just root), I
lose job control. Combined with the fact that emacs running as root
has no problem whatsoever with shell jobcontrol, this suggests that
the problem is that emacs running as me can't do jobcontrol on
subshells running as some other user, due to lack of permission.
> Not really a bug, just an emacs limitation.
I agree that this may well be more of a problem with emacs itself
(or how it is built/configured) than it is with any other part of the
system, and therefore it is more of a problem for the Emacs community
to solve, and less of a RedHat problem. That said, I have none of
these problems running emacs 20.3 and 20.4 on my SGI Irix 6.5.5
system, so I don't consider this a fundamental limitation that can't
be resolved. Perhaps it's either a bug or feature of Irix that
job control permission works differently from GNU/Linux?
Okay, what it boils down to is emacs being unhappy about the fact that su is
resetting the terminal as a security measure.
I am not aware of any workaround for this problem, and making su not reset its
terminal is not an option