Bug 4541
Summary: | no job control after su - root in emacs M-x shell | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | dunwoody |
Component: | emacs | Assignee: | Cristian Gafton <gafton> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-02-16 23:58:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
dunwoody
1999-08-16 06:33:39 UTC
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' interference. 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 |