[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 23.0.50; source of warning in *shell* buffer
From: |
Peter Dyballa |
Subject: |
Re: 23.0.50; source of warning in *shell* buffer |
Date: |
Fri, 19 Oct 2007 16:27:22 +0200 |
Am 19.10.2007 um 14:46 schrieb Andreas Schwab:
Peter Dyballa writes:
When I invoke M-x shell the new buffer starts with:
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
Where is the source for these messages?
They are most likely coming from the shell.
Ahh, strings reveals them in tcsh! Except the 'Bad file descriptor'
string, which was found in:
./src/w32.c:2952: WSAEBADF , "Bad file descriptor",
I am sure that I am not using Losedows ...
What are the criterions for this warning?
Probably the shell could not open /dev/tty, ie. it has no controlling
terminal. That happens when the process is using pipes instead of
ptys.
Indeed. Tty does not return a pty's name, and lsof shows that FILE
structs are in use:
COMMAND PID USER FD NAME
tcsh 9977 pete 16r 0x04bb9380 file struct, ty=0x6, op=0x3823ec
tcsh 9977 pete 17w 0x04791b40 file struct, ty=0x6, op=0x3823ec
tcsh 9977 pete 18w 0x04bb9fb0 file struct, ty=0x6, op=0x3823ec
tcsh 9977 pete 19r 0x0529d4c0 file struct, ty=0x6, op=0x3823ec
Which elements are necessary for job control?
The shell needs to be able to manipulate the process group of the
controlling terminal.
Is this really needed in the *shell* buffer? Term offers a more
complete terminal emulation. In *terminal* buffer I cannot see the
warnings and tty returns a pty's name.
--
Mit friedvollen Grüßen
Pete
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners.
Ernest Jan Plugge