* M-x shell not working
@ 2005-10-18 6:34 Sunil Yeddu
2005-10-18 9:27 ` Peter Dyballa
0 siblings, 1 reply; 13+ messages in thread
From: Sunil Yeddu @ 2005-10-18 6:34 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 2328 bytes --]
Hi all,
We have recently migrated to emacs 21.4 from emacs 20.7 in our environment.
In emacs-21.4, I get this error when I do M-x shell.
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
stty: standard input: Invalid argument
exit
Process shell finished
We use clearcase for source control and this is happening inside a clearcase
view. Outside a view, there is no problem. We had no problem at all in
emacs-20.7, even inside a clearcase view. In emacs-21.4, it is working some
times but most of the times it is not. Looks like pty is not being
allocated.
I did some debugging and found the following information. In emacs-21.4, in
the rare case when M-x shell works, tty allocated is like '/view/dev/ttyp7'
. '/view' is due to clearcase, may be some virtual path. The actual path
starts from '/dev/...' ie. Removing '/view' would give the path of the tty
in our system. In emacs-20.7, the tty allocated is like '/view/43'. It is
always of the form '/view/' followed by a number. This indicates that the
tty allocation system is changed in emacs-21.4. In emacs-20.7, looks like it
is doing some virtual allocation as it is just a number. But in emacs-21.4,
it is allocating from /dev. We have sufficient number of ttys too.
% ls /dev/tty* | wc -l
905
Emacs is not able to pick up a free one? Also I noticed that, in emacs-21.4,
when M-x shell works, it works for some time before it stops working and
goes back to its usual state. During this time, it is able to allocate ptys
in serial order without any problem, when we invoke shell from different
emacs sessions. I suspect that when it is able to capture some tty in a
specific range, it is able to obtain the remaining without any problem. I
ruled out the possibility that ttys are really exhausted because, while I
could open shell from emacs-21.4, other users could'nt do it on the same
machine during the same time.
OS is linux. I have verified that process-connection-type is set to t. So
this is not the same problem as Mac users have reported. Also, I started
emacs with -q option. So there is nothing in my .emacs file which could have
caused this problem.
I hope this infomation which I collected from my debugging would be of help.
I could not proceed further. Can someone help?
Sunil
[-- Attachment #1.2: Type: text/html, Size: 2983 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-18 6:34 M-x shell not working Sunil Yeddu
@ 2005-10-18 9:27 ` Peter Dyballa
2005-10-18 11:56 ` Sunil Yeddu
0 siblings, 1 reply; 13+ messages in thread
From: Peter Dyballa @ 2005-10-18 9:27 UTC (permalink / raw)
Cc: help-gnu-emacs
Am 18.10.2005 um 08:34 schrieb Sunil Yeddu:
> Warning: no access to tty (Bad file descriptor).
> Thus no job control in this shell.
> stty: standard input: Invalid argument <<<<<<<<<<<
> exit
>
> Process shell finished
This is very familiar for me on Mac OS X. Here it's found that using
ttys is not reliable. (setq process-connection-type t) in .emacs
'corrects' this.
Your problem is that some shell rc file writes something into /dev/tty
or such without first checking whether it's allowed or useful. So check
the code in your shell's rc file(s), for example make the shell
verbosely list what it's doing during its initialisation while working
on the rc file(s)!
--
Greetings
Pete
“One cannot live by television, video games, top ten CDs, and dumb
movies alone”
(Amiri Baraka 1999)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-18 9:27 ` Peter Dyballa
@ 2005-10-18 11:56 ` Sunil Yeddu
2005-10-18 18:28 ` Kevin Rodgers
0 siblings, 1 reply; 13+ messages in thread
From: Sunil Yeddu @ 2005-10-18 11:56 UTC (permalink / raw)
Cc: help-gnu-emacs
[-- Attachment #1.1: Type: text/plain, Size: 1729 bytes --]
Hi,
There was a 'stty sane' line in my .cshrc which is causing the Invalid
argument message. I removed it and that erorr message has gone away. Thanks,
Pete.
I also noticed that setting TERM env to any value is causing shell to exit.
I removed the line which sets TERM env from my cshrc and I was able to
access shell !!! But the warning message is still there.
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
And setting TERM env in it is causing the shell to exit immediately. I guess
this is because of tty not being allocated. From the shell in emacs when I
type tty, I see...
$ tty
not a tty
So there is no solution to the original problem yet, as removing the line
which sets TERM env cannot be a permanent solution.
Sunil
On 10/18/05, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
>
> Am 18.10.2005 um 08:34 schrieb Sunil Yeddu:
>
> > Warning: no access to tty (Bad file descriptor).
> > Thus no job control in this shell.
> > stty: standard input: Invalid argument <<<<<<<<<<<
> > exit
> >
> > Process shell finished
>
> This is very familiar for me on Mac OS X. Here it's found that using
> ttys is not reliable. (setq process-connection-type t) in .emacs
> 'corrects' this.
>
> Your problem is that some shell rc file writes something into /dev/tty
> or such without first checking whether it's allowed or useful. So check
> the code in your shell's rc file(s), for example make the shell
> verbosely list what it's doing during its initialisation while working
> on the rc file(s)!
>
> --
> Greetings
>
> Pete
>
> "One cannot live by television, video games, top ten CDs, and dumb
> movies alone"
> (Amiri Baraka 1999)
>
>
[-- Attachment #1.2: Type: text/html, Size: 2395 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-18 11:56 ` Sunil Yeddu
@ 2005-10-18 18:28 ` Kevin Rodgers
2005-10-19 6:36 ` Sunil Yeddu
0 siblings, 1 reply; 13+ messages in thread
From: Kevin Rodgers @ 2005-10-18 18:28 UTC (permalink / raw)
Sunil Yeddu wrote:
> I also noticed that setting TERM env to any value is causing shell
> to exit. I removed the line which sets TERM env from my cshrc and I was
> able to access shell !!! But the warning message is still there.
>
> Warning: no access to tty (Bad file descriptor).
> Thus no job control in this shell.
>
> And setting TERM env in it is causing the shell to exit
> immediately. I guess this is because of tty not being allocated. From
> the shell in emacs when I type tty, I see...
> $ tty
> not a tty
>
> So there is no solution to the original problem yet, as removing
> the line which sets TERM env cannot be a permanent solution.
But moving it to your .login file where it belongs is a solution.
--
Kevin Rodgers
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-18 18:28 ` Kevin Rodgers
@ 2005-10-19 6:36 ` Sunil Yeddu
2005-10-19 9:00 ` Peter Dyballa
0 siblings, 1 reply; 13+ messages in thread
From: Sunil Yeddu @ 2005-10-19 6:36 UTC (permalink / raw)
Cc: help-gnu-emacs
[-- Attachment #1.1: Type: text/plain, Size: 1019 bytes --]
>
>
> > So there is no solution to the original problem yet, as removing
> > the line which sets TERM env cannot be a permanent solution.
>
> But moving it to your .login file where it belongs is a solution.
Kevin, as you suggested I tried moving 'setenv TERM vt100' to .login file.
But .login file is read only once. And everytime we open a new shell using
xterm it is not getting the TERM variable.
Also we have all the settings in a common cshrc file which we 'source' from
our ~/.cshrc. And setting TERM is done in that common file. Making changes
to that file will not be a good solution to get emacs shell working as it
will have wider implications. Also I feel, fiddling around with TERM
variable is just a workaround. The problem of tty is still there. I still
get warning message when I enter shell in emacs with 'setenv TERM ..'
commented out.
Since it is working in emacs-20.7, there is some change done in emacs-21.4.
If that is identified then may be we can find a solution.
Sunil
[-- Attachment #1.2: Type: text/html, Size: 1354 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-19 6:36 ` Sunil Yeddu
@ 2005-10-19 9:00 ` Peter Dyballa
2005-10-19 10:43 ` Sunil Yeddu
2005-10-20 9:02 ` Peter Dyballa
0 siblings, 2 replies; 13+ messages in thread
From: Peter Dyballa @ 2005-10-19 9:00 UTC (permalink / raw)
Cc: Kevin Rodgers, help-gnu-emacs
Am 19.10.2005 um 08:36 schrieb Sunil Yeddu:
> And everytime we open a new shell using xterm it is not getting the
> TERM variable.
So make it in xterm a login shell! xterm -ls ...
> Also we have all the settings in a common cshrc file which we
> 'source' from our ~/.cshrc. And setting TERM is done in that common
> file.
Why do you want to set TERM in Emacs' shell? GNU Emacs is clever enough
to set it itself (to dumb). My previous hint with checking whether TERM
exists is valuable: only if not set source that group-wide .cshrc file!
The missing pieces from this file can be put into .emacs_csh to
initialise Emacs *shell* buffer.
> Also I feel, fiddling around with TERM variable is just a workaround.
> The problem of tty is still there. I still get warning message when I
> enter shell in emacs with 'setenv TERM ..' commented out.
> Since it is working in emacs-20.7, there is some change done in
> emacs-21.4. If that is identified then may be we can find a solution.
You should be a bit more specific in which OS this happens. And check
GNU Emacs' eshell too! This one is more kind of a terminal emulation.
*shell* is just a buffer in which a UNIX shell interpreter runs which
does not need much code from a shell rc file.
--
Greetings
Pete
"I love deadlines. I love the whooshing noise they make as they go by"
(Douglas Adams)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-19 9:00 ` Peter Dyballa
@ 2005-10-19 10:43 ` Sunil Yeddu
2005-10-20 9:02 ` Peter Dyballa
1 sibling, 0 replies; 13+ messages in thread
From: Sunil Yeddu @ 2005-10-19 10:43 UTC (permalink / raw)
Cc: help-gnu-emacs
[-- Attachment #1.1: Type: text/plain, Size: 2197 bytes --]
> Why do you want to set TERM in Emacs' shell? GNU Emacs is clever enough
> to set it itself (to dumb). My previous hint with checking whether TERM
> exists is valuable: only if not set source that group-wide .cshrc file!
> The missing pieces from this file can be put into .emacs_csh to
> initialise Emacs *shell* buffer.
.cshrc will be executed before .emacs_csh. Where should I put the line 'if
term is not set source the group-wide cshrc' ? TERM is also being set in
that common cshrc file. The goal is: it should not be set only for emacs
shell.
I found that emacs shell sets an environment variable EMACS to 't'. So only
if that is set, I can set TERM env in common cshrc file. So this is working
now. But this warning message is still there.
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
Although almost everything is fine, there are some problems because it
does'nt have a tty. For example, ftp is not working. I can't see anything on
the screen although ftp commands are working, because there is no tty.
You should be a bit more specific in which OS this happens. And check
> GNU Emacs' eshell too! This one is more kind of a terminal emulation.
> *shell* is just a buffer in which a UNIX shell interpreter runs which
> does not need much code from a shell rc file.
This is happening only in linux OS as I mentioned in my first mail. On
Solaris it is ok.
Our scenario is like this. We have common cshrc and aliasrc files which are
source controlled. These files, which set up our environment, must be
sourced by every member in a large team. Recently we upgraded emacs and
since then we are having this problem. I tried eshell too. But eshell
does'nt take .cshrc. Sourcing the file explicitly if causing some errors as
eshell is unable to understand some shell programming constructs like
'foreach'. As cshrc is failing to load completely, our environment is not
being set in eshell.
Trying to get emacs working and allocate appropriate tty seems to be the
best way for me. As I said, emacs-21.4 is able to allocate it sometimes. May
be the code which does tty allocation needs a fix.
Thanks,
Sunil
[-- Attachment #1.2: Type: text/html, Size: 3141 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: M-x shell not working
2005-10-19 9:00 ` Peter Dyballa
2005-10-19 10:43 ` Sunil Yeddu
@ 2005-10-20 9:02 ` Peter Dyballa
[not found] ` <13ecef2d0510200309v19be5860g8d85c8ebcfd70585@mail.gmail.com>
1 sibling, 1 reply; 13+ messages in thread
From: Peter Dyballa @ 2005-10-20 9:02 UTC (permalink / raw)
Cc: Emacs help
Am 19.10.2005 um 11:00 schrieb Peter Dyballa:
> And check GNU Emacs' eshell too!
Sunil,
I'm sorry: I mentioned the wrong tool yesterday. It's not eshell, the
shell in Elisp, that I wanted to recommend, but terminal! M-x term RET
will create a *terminal* buffer that behaves better as a terminal
emulation. Please try whether terminal behaves more like shell before!
Most of its features are described in a description of term-mode (C-h f
term RET, position cursor on 'term-mode' and press enter -- I don't
know whether there is better way to access this information). In info
you'll find in the Emacs department a node 'Term mode' -- quite short.
--
Greetings
Pete
Got Mole problems?
Call Avogadro 6.02 x 10^23
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-10-25 6:19 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-18 6:34 M-x shell not working Sunil Yeddu
2005-10-18 9:27 ` Peter Dyballa
2005-10-18 11:56 ` Sunil Yeddu
2005-10-18 18:28 ` Kevin Rodgers
2005-10-19 6:36 ` Sunil Yeddu
2005-10-19 9:00 ` Peter Dyballa
2005-10-19 10:43 ` Sunil Yeddu
2005-10-20 9:02 ` Peter Dyballa
[not found] ` <13ecef2d0510200309v19be5860g8d85c8ebcfd70585@mail.gmail.com>
2005-10-20 12:02 ` Fwd: " Sunil Yeddu
[not found] ` <6172b6c2efe01b4025c9d58fe9624236@Web.DE>
2005-10-20 12:03 ` Sunil Yeddu
2005-10-20 13:45 ` Eli Zaretskii
2005-10-21 12:52 ` Sunil Yeddu
2005-10-25 6:19 ` Sunil Yeddu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).