all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 23.0.50; source of warning in *shell* buffer
@ 2007-10-19 12:17 Peter Dyballa
  2007-10-19 12:46 ` Andreas Schwab
  2007-10-19 14:13 ` Stefan Monnier
  0 siblings, 2 replies; 8+ messages in thread
From: Peter Dyballa @ 2007-10-19 12:17 UTC (permalink / raw)
  To: emacs-pretest-bug

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 12:17 23.0.50; source of warning in *shell* buffer Peter Dyballa
@ 2007-10-19 12:46 ` Andreas Schwab
  2007-10-19 14:27   ` Peter Dyballa
  2007-10-19 14:13 ` Stefan Monnier
  1 sibling, 1 reply; 8+ messages in thread
From: Andreas Schwab @ 2007-10-19 12:46 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: emacs-pretest-bug

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 12:17 23.0.50; source of warning in *shell* buffer Peter Dyballa
  2007-10-19 12:46 ` Andreas Schwab
@ 2007-10-19 14:13 ` Stefan Monnier
  2007-10-19 15:12   ` Peter Dyballa
  1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2007-10-19 14:13 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: emacs-pretest-bug

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 12:46 ` Andreas Schwab
@ 2007-10-19 14:27   ` Peter Dyballa
  2007-10-19 16:06     ` Eli Zaretskii
  2007-10-19 16:18     ` Jason Rumney
  0 siblings, 2 replies; 8+ messages in thread
From: Peter Dyballa @ 2007-10-19 14:27 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: emacs-pretest-bug


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 14:13 ` Stefan Monnier
@ 2007-10-19 15:12   ` Peter Dyballa
  0 siblings, 0 replies; 8+ messages in thread
From: Peter Dyballa @ 2007-10-19 15:12 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-pretest-bug


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 14:27   ` Peter Dyballa
@ 2007-10-19 16:06     ` Eli Zaretskii
  2007-10-19 22:55       ` Peter Dyballa
  2007-10-19 16:18     ` Jason Rumney
  1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2007-10-19 16:06 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: schwab, emacs-pretest-bug

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 14:27   ` Peter Dyballa
  2007-10-19 16:06     ` Eli Zaretskii
@ 2007-10-19 16:18     ` Jason Rumney
  1 sibling, 0 replies; 8+ messages in thread
From: Jason Rumney @ 2007-10-19 16:18 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: Andreas Schwab, emacs-pretest-bug

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 23.0.50; source of warning in *shell* buffer
  2007-10-19 16:06     ` Eli Zaretskii
@ 2007-10-19 22:55       ` Peter Dyballa
  0 siblings, 0 replies; 8+ messages in thread
From: Peter Dyballa @ 2007-10-19 22:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Andreas Schwab, emacs-pretest-bug, Jason Rumney


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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-10-19 22:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-19 12:17 23.0.50; source of warning in *shell* buffer Peter Dyballa
2007-10-19 12:46 ` Andreas Schwab
2007-10-19 14:27   ` Peter Dyballa
2007-10-19 16:06     ` Eli Zaretskii
2007-10-19 22:55       ` Peter Dyballa
2007-10-19 16:18     ` Jason Rumney
2007-10-19 14:13 ` Stefan Monnier
2007-10-19 15:12   ` Peter Dyballa

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.