23.0.50; source of warning in *shell* buffer

23.0.50; source of warning in *shell* buffer

[Peter Dyballa]

Hello!

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? What are the criterions for  
this warning? Which elements are necessary for job control?

There is some simple job control: & works. And fg works, too.

Mac OS X 10.4.10.

--
Greetings

   Pete

Upgraded:  Didn't work the first time.

Re: 23.0.50; source of warning in *shell* buffer

[Andreas Schwab]

Peter Dyballa <Peter_Dyballa@Freenet.DE> 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.

> 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.

> Which elements are necessary for job control?

The shell needs to be able to manipulate the process group of the
controlling terminal.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 23.0.50; source of warning in *shell* buffer

[Stefan Monnier]

> 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? What are the criterions for  this
> warning? Which elements are necessary for job control?

> There is some simple job control: & works. And fg works, too.

> Mac OS X 10.4.10.

Check the value of process-connection-type.
If it's nil, then try to figure out why,


        Stefan

Re: 23.0.50; source of warning in *shell* buffer

[Peter Dyballa]

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

Re: 23.0.50; source of warning in *shell* buffer

[Peter Dyballa]

Am 19.10.2007 um 16:13 schrieb Stefan Monnier:

>> Mac OS X 10.4.10.
>
> Check the value of process-connection-type.
> If it's nil, then try to figure out why,

It's nil. In src/s/darwin.h I have:


#define SYSTEM_TYPE "darwin"

/* NOMULTIPLEJOBS should be defined if your system's shell
  does not have "job control" (the ability to stop a program,
  run some other program, then continue the first one).  */

/* #define NOMULTIPLEJOBS */

/* Emacs can read input using SIGIO and buffering characters itself,
    or using CBREAK mode and making C-g cause SIGINT.
    The choice is controlled by the variable interrupt_input.

    Define INTERRUPT_INPUT to make interrupt_input = 1 the default  
(use SIGIO)

    Emacs uses the presence or absence of the SIGIO and BROKEN_SIGIO  
macros
    to indicate whether or not signal-driven I/O is possible.  It uses
    INTERRUPT_INPUT to decide whether to use it by default.

    SIGIO can be used only on systems that implement it (4.2 and 4.3).
    CBREAK mode has two disadvantages
      1) At least in 4.2, it is impossible to handle the Meta key  
properly.
         I hear that in system V this problem does not exist.
      2) Control-G causes output to be discarded.
         I do not know whether this can be fixed in system V.

    Another method of doing input is planned but not implemented.
    It would have Emacs fork off a separate process
    to read the input and send it to the true Emacs process
    through a pipe. */

#define INTERRUPT_INPUT

/* Letter to use in finding device name of first pty,
   if system supports pty's.  'a' means it is /dev/ptya0  */

#define FIRST_PTY_LETTER 'p'

/*
  *	Define HAVE_TERMIOS if the system provides POSIX-style
  *	functions and macros for terminal control.
  *
  *	Define HAVE_TERMIO if the system provides sysV-style ioctls
  *	for terminal control.
  *
  *	Do not define both.  HAVE_TERMIOS is preferred, if it is
  *	supported on your system.
  */

#define HAVE_TERMIOS
/* #define HAVE_TERMIO */

#define NO_TERMIO

/*
  *	Define HAVE_PTYS if the system supports pty devices.
  *      Note: PTYs are broken on darwin <6.  Use at your own risk.
  */

#define HAVE_PTYS

/**
  * PTYs only work correctly on Darwin 7 or higher.  So make the
  * default for process-connection-type dependent on the kernel
  * version.
  */
#define MIN_PTY_KERNEL_VERSION '7'

...

/* subprocesses should be defined if you want to
    have code for asynchronous subprocesses
    (as used in M-x compile and M-x shell).
    This is generally OS dependent, and not supported
    under most USG systems. */

#define subprocesses


BSD_2 and BSD_SYSTEM are defined before. It looks fine for me, except  
the

	#define NO_TERMIO

looks odd ...

--
Greetings

   Pete

"Isn't vi that text editor with two modes... one that beeps and one
that corrupts your file?" -- Dan Jacobson, on comp.os.linux.advocacy

Re: 23.0.50; source of warning in *shell* buffer

[Eli Zaretskii]

> From: Peter Dyballa <Peter_Dyballa@Freenet.DE>
> Date: Fri, 19 Oct 2007 16:27:22 +0200
> Cc: emacs-pretest-bug@gnu.org
> 
> >> 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 ...

"Bad file descriptor" is the standard string describing EBADF on many
Posix systems, if you want to find it, look in libc.so.  What you
found above is just mapping from the Windows socket error codes to
such standard strings.

Re: 23.0.50; source of warning in *shell* buffer

[Jason Rumney]

Peter Dyballa wrote:
> 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 ...
Check libc for the same message. WSAEBADF is the Windows equivalant of
EBADF (an error return code from many file and socket related
functions). That definition in w32.c is probably just making it display
the same message that is expected on other platforms. Of course, if the
message is coming from libc, then it doesn't tell you anything about the
source, but based on the other messages, tcsh is a likely culprit.

Re: 23.0.50; source of warning in *shell* buffer

[Peter Dyballa]

Am 19.10.2007 um 18:06 schrieb Eli Zaretskii:

> "Bad file descriptor" is the standard string describing EBADF on many
> Posix systems, if you want to find it, look in libc.so.  What you
> found above is just mapping from the Windows socket error codes to
> such standard strings.

Of course! I see now – that the question is: what is presumingly lisp/ 
shell.el doing wrong in contrast to lisp/terminal.el when creating  
the buffer and launching the login shell?

--
Greetings

   Pete

The light at the end of the tunnel has been turned off due to budget  
cuts.