grep-use-null-device

grep-use-null-device

[Emilio Lopes]

The documentation of this variable says:

   grep-use-null-device's value is nil

   If t, append the value of `null-device' to `grep' commands.
   This is done to ensure that the output of grep includes the filename of
   any match in the case where only a single file is searched, and is not
   necessary if the grep program used supports the `-H' option.

   The default value of this variable is set up by `grep-compute-defaults';
   call that function before using this variable in your program.

   You can customize this variable.

   Defined in `grep'.


If I understood it right, it says that I don't need a "/dev/null"
appended to my grep commands if my grep program supports the
option "-H".

Let's see:

   ~% grep --version
   grep (GNU grep) 2.5.1

   Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions. There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

   ~% grep --help | grep -- -H
     -H, --with-filename       print the filename for each match

So, my grep program supports "-H" but it apparently has not the
expected semantics.

As a result, if I forget to provide a filename to "M-x grep" it will run
forever, waiting for me to kill it.

Do I have the "wrong" grep?

Is there a case where having a `null-device' too much will hurt?

Re: grep-use-null-device

[Richard M. Stallman]

    So, my grep program supports "-H" but it apparently has not the
    expected semantics.

That is a very vague statement.  It tells us nothing.  Why don't you
tell us what DOES happen, instead of just saying you think it is wrong
somehow.

Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the
necessary information so we can fix the bug.

Re: grep-use-null-device

[Emilio Lopes]

Emilio Lopes writes:

> As a result, if I forget to provide a filename to "M-x grep" it will
> run forever, waiting for me to kill it.

Richard M Stallman writes:

>     So, my grep program supports "-H" but it apparently has not the
>     expected semantics.

> That is a very vague statement.  It tells us nothing.

No, no.  It's very concrete if you consider the rest of the message,
which you didn't quote.  Anyway, I understand the problem better now.

If the user forgets to provide a filename to "M-x grep" (as in
"grep -nH foo") it will run indefinitely waiting for input from
stdin until killed.  In such cases it's useful to have `null-device'
appended, even if the grep program supports the option "-H" (which
has an other purpose anyway).

One could even argue if Emacs should not append *two* instances of
`null-device', in the case the use just press enter at the grep prompt
without even typing a regexp.

Re: grep-use-null-device

[David Kastrup]

Emilio Lopes <eclig@gmx.net> writes:

> Emilio Lopes writes:
>
>> As a result, if I forget to provide a filename to "M-x grep" it will
>> run forever, waiting for me to kill it.
>
> Richard M Stallman writes:
>
>>     So, my grep program supports "-H" but it apparently has not the
>>     expected semantics.
>
>> That is a very vague statement.  It tells us nothing.
>
> No, no.  It's very concrete if you consider the rest of the message,
> which you didn't quote.  Anyway, I understand the problem better now.
>
> If the user forgets to provide a filename to "M-x grep" (as in
> "grep.-nH.foo") it will run indefinitely waiting for input from
> stdin until killed.  In such cases it's useful to have `null-device'
> appended, even if the grep program supports the option "-H" (which
> has an other purpose anyway).
>
> One could even argue if Emacs should not append *two* instances of
> `null-device', in the case the use just press enter at the grep prompt
> without even typing a regexp.

I think what rather should be done is that standard input on the grep
process gets closed.  That requires no special options, and it will
lead to a sensible result without obscure extra options.

grep-use-null-device is just for getting file names on matches, not
for dealing with bad commands.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: grep-use-null-device

[Juri Linkov]

> If the user forgets to provide a filename to "M-x grep" (as in
> "grep -nH foo") it will run indefinitely waiting for input from
> stdin until killed.  In such cases it's useful to have `null-device'
> appended, even if the grep program supports the option "-H" (which
> has an other purpose anyway).

Sometimes I miss a space between the regexp and the file name,
i.e. instead of `grep -nH foo *' I type `grep -nH foo*' where
`foo*' is interpreted by grep as a regexp with the empty file name.
It takes some time before starting to worry why grep doesn't finish.

`/dev/null' you proposed is of no help.  It causes grep to print the
finishing message `no matches found' which gives the false impression
that the search string was not found by grep.  This is worse than
forcing you to type C-c C-k to kill the grep process that helps you
to discover your mistake.

Maybe grep.el should try to parse the grep command line and warn the
user about a missing file name (e.g. by highlighting the command in
the grep buffer in `compilation-error' face).  This helps to notice
the mistake sooner, but parsing the command is an unreliable method.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: grep-use-null-device

[Karl Chen]

>>>>> On 2005-08-15 19:25 PDT, Richard M Stallman writes:

    rms>     So, my grep program supports "-H" but it apparently
    rms>     has not the expected semantics.

    rms> That is a very vague statement.  It tells us nothing.

Emilio is reiterating the same issue I raised on 2005-02-03 [1]:

    Emilio> if I forget to provide a filename to "M-x grep" it
    Emilio> will run forever, waiting for me to kill it.

Kevin Rodgers posted a patch that would allow `grep' to close
stdin, solving this annoyance, but it appears it was never
followed up.


[1] http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00090.html

[2] http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00452.html

-- 
Karl 2005-08-16 04:41

Re: grep-use-null-device

[Emilio Lopes]

Karl Chen writes:

> Kevin Rodgers posted a patch that would allow `grep' to close stdin,
> solving this annoyance, but it appears it was never followed up.

> http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00452.html

Yes, that's exactly what David Kastrup suggested in another reply.

Thanks for posting the URL, though it seems that the web interface at
lists.gnu.org eats multiple spaces.  Here is the Gmane URL for the
original post from Kevin Rodgers with correct indentation:

   http://article.gmane.org/gmane.emacs.devel/33146

-- 
Emílio C. Lopes
Munich, Germany

Re: grep-use-null-device

[Emilio Lopes]

David Kastrup writes:

> I think what rather should be done is that standard input on the
> grep process gets closed.  That requires no special options, and it
> will lead to a sensible result without obscure extra options.

This seems a rather clean solution.  Karl Chen pointed out that Kevin
Rodgers already posted such a patch to this list.  Here is the URL:

   http://article.gmane.org/gmane.emacs.devel/33146

I'll try his patch out.

> grep-use-null-device is just for getting file names on matches, not
> for dealing with bad commands.

That was my confusion.  It saved me a lot of times as I forgot to
provide grep with filenames, so that for me it was its obvious purpose.
A nice hack indeed.

Re: grep-use-null-device

[Richard M. Stallman]

    Thanks for posting the URL, though it seems that the web interface at
    lists.gnu.org eats multiple spaces.  Here is the Gmane URL for the
    original post from Kevin Rodgers with correct indentation:

       http://article.gmane.org/gmane.emacs.devel/33146

Can someone please install it?

Re: grep-use-null-device

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Wed, 17 Aug 2005 02:25:39 -0400
> Cc: emacs-devel@gnu.org
> 
>     Thanks for posting the URL, though it seems that the web interface at
>     lists.gnu.org eats multiple spaces.  Here is the Gmane URL for the
>     original post from Kevin Rodgers with correct indentation:
> 
>        http://article.gmane.org/gmane.emacs.devel/33146
> 
> Can someone please install it?

Done.

In your response to that message, you mentioned something about
testing for COMINT in start-compilation.  I didn't inderstand what you
meant, so I didn't do anything about that.  See:

  http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00510.html

"^D^H^H" in process output on Darwin (Was Re: grep-use-null-device)

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 20 Aug 2005 15:22:41 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> Thanks for posting the URL, though it seems that the web interface
>> at lists.gnu.org eats multiple spaces.  Here is the Gmane URL for
>> the original post from Kevin Rodgers with correct indentation:
>> 
>> http://article.gmane.org/gmane.emacs.devel/33146
>> 
>> Can someone please install it?

> Done.

With this change, we sometimes see "^D^H^H" at the head of the output
of grep on Darwin/Mac OS X with whichever window systems (^H is
actually in one character).  It looks as if the tty echo option is not
disabled and ^D is echoed back in response to process-send-eof.

I think this is because Emacs may send some data before a subprocess
completes tty options setup.  On Darwin, vfork is defined as fork for
the reason mentioned in src/s/darwin.h.

/* The following solves the problem that Emacs hangs when evaluating
   (make-comint "test0" "/nodir/nofile" nil "") when /nodir/nofile
   does not exist.  */
#undef HAVE_WORKING_VFORK
#define vfork fork
#define DONT_REOPEN_PTY

(It actually hangs on Mac OS X 10.1.5 and 10.2.8 if
process-connection-type is set to t.  On Mac OS X 10.3.9 it seems not
to hang.  Are there any other problems with vfork on Mac OS X 10.3,
which is based on Darwin 7?)

Unlike vfork, the parent process may run before the child process
executes the code between (v)fork and execve/_exit if fork is used.
The current Emacs disables the tty echo option in the child process
(for USG systems?) by calling child_setup_tty.

The following patch does tty options setup before forking, and it
works for me.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/process.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/process.c,v
retrieving revision 1.463
diff -c -r1.463 process.c
*** src/process.c	15 Aug 2005 08:44:53 -0000	1.463
--- src/process.c	27 Aug 2005 01:25:30 -0000
***************
*** 1793,1798 ****
--- 1793,1802 ----
  #endif
        if (forkin < 0)
  	report_file_error ("Opening pty", Qnil);
+       /* In the case that vfork is defined as fork, the parent process
+ 	 (Emacs) may send some data before the child process completes
+ 	 tty options setup.  So we setup tty before forking.  */
+       child_setup_tty (forkout);
  #else
        forkin = forkout = -1;
  #endif /* not USG, or USG_SUBTTY_WORKS */

Re: "^D^H^H" in process output on Darwin

[Stefan Monnier]

> With this change, we sometimes see "^D^H^H" at the head of the output
> of grep on Darwin/Mac OS X with whichever window systems (^H is
> actually in one character).  It looks as if the tty echo option is not

I've seen this problem also.  I've even added a workaround for it in
cvs-parse-process (in pcvs.el) because it otherwise confused the parser of
PCL-CVS.


        Stefan

Re: grep-use-null-device

[Juri Linkov]

>>     Thanks for posting the URL, though it seems that the web interface at
>>     lists.gnu.org eats multiple spaces.  Here is the Gmane URL for the
>>     original post from Kevin Rodgers with correct indentation:
>> 
>>        http://article.gmane.org/gmane.emacs.devel/33146
>> 
>> Can someone please install it?
>
> Done.

With this change, when grep finishes too quickly (for example, after
searching in a nonexistent file), `process-send-eof' fails with the
following error:

Debugger entered--Lisp error: (error "Process grep not running")
  process-send-eof(#<process grep>)
  compilation-start("grep -inH -e search file" grep-mode nil nil)
  grep("grep -inH -e search file")
  call-interactively(grep)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

`compilation-start' needs to check if the process is running
before calling `process-send-eof':

Index: lisp/progmodes/compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.378
diff -c -r1.378 compile.el
*** lisp/progmodes/compile.el	27 Aug 2005 14:38:21 -0000	1.378
--- lisp/progmodes/compile.el	29 Aug 2005 22:18:30 -0000
***************
*** 1032,1038 ****
  						       outbuf command))))
  	      ;; Make the buffer's mode line show process state.
  	      (setq mode-line-process '(":%s"))
! 	      (when compilation-disable-input
  		(process-send-eof proc))
  	      (set-process-sentinel proc 'compilation-sentinel)
  	      (set-process-filter proc 'compilation-filter)
--- 1032,1039 ----
  						       outbuf command))))
  	      ;; Make the buffer's mode line show process state.
  	      (setq mode-line-process '(":%s"))
! 	      (when (and compilation-disable-input
! 			 (eq (process-status proc) 'run))
  		(process-send-eof proc))
  	      (set-process-sentinel proc 'compilation-sentinel)
  	      (set-process-filter proc 'compilation-filter)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: grep-use-null-device

[Richard M. Stallman]

    `compilation-start' needs to check if the process is running
    before calling `process-send-eof':

Please install your patch--and thanks.

Re: grep-use-null-device

[Stefan Monnier]

> With this change, when grep finishes too quickly (for example, after
> searching in a nonexistent file), `process-send-eof' fails with the
> following error:

> Debugger entered--Lisp error: (error "Process grep not running")
>   process-send-eof(#<process grep>)
>   compilation-start("grep -inH -e search file" grep-mode nil nil)
>   grep("grep -inH -e search file")
>   call-interactively(grep)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)

> `compilation-start' needs to check if the process is running
> before calling `process-send-eof':

That's odd.  AFAICT no blobking operation takes place between the
start-process and the process-send-eof, so the process-status should still
be `run' no matter how quickly the process exits (because Emacs shouldn't
process the SIGCHLD it receives until later).

What am I missing?


        Stefan


> Index: lisp/progmodes/compile.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
> retrieving revision 1.378
> diff -c -r1.378 compile.el
> *** lisp/progmodes/compile.el	27 Aug 2005 14:38:21 -0000	1.378
> --- lisp/progmodes/compile.el	29 Aug 2005 22:18:30 -0000
> ***************
> *** 1032,1038 ****
>   						       outbuf command))))
>   	      ;; Make the buffer's mode line show process state.
>   	      (setq mode-line-process '(":%s"))
> ! 	      (when compilation-disable-input
>   		(process-send-eof proc))
>   	      (set-process-sentinel proc 'compilation-sentinel)
>   	      (set-process-filter proc 'compilation-filter)
> --- 1032,1039 ----
>   						       outbuf command))))
>   	      ;; Make the buffer's mode line show process state.
>   	      (setq mode-line-process '(":%s"))
> ! 	      (when (and compilation-disable-input
> ! 			 (eq (process-status proc) 'run))
>   		(process-send-eof proc))
>   	      (set-process-sentinel proc 'compilation-sentinel)
>   	      (set-process-filter proc 'compilation-filter)

> -- 
> Juri Linkov
> http://www.jurta.org/emacs/



> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: grep-use-null-device

[Juri Linkov]

>> `compilation-start' needs to check if the process is running
>> before calling `process-send-eof':
>
> That's odd.  AFAICT no blobking operation takes place between the
> start-process and the process-send-eof, so the process-status should still
> be `run' no matter how quickly the process exits (because Emacs shouldn't
> process the SIGCHLD it receives until later).
>
> What am I missing?

The process exits during execution of create_process.  The gdb log below
with a breakpoint on sigchld_handler demonstrates what really happens:

Breakpoint 4, sigchld_handler (signo=17) at process.c:6249
6249              XSETINT (p->raw_status_low, u.i & 0xffff);
(gdb) n
6250              XSETINT (p->raw_status_high, u.i >> 16);
(gdb) n
6253              if ((WIFSIGNALED (w) || WIFEXITED (w))
(gdb) n
6260                  FD_CLR (XINT (p->infd), &input_wait_mask);
(gdb) n
6261                  FD_CLR (XINT (p->infd), &non_keyboard_wait_mask);
(gdb) p w
$1 = 512     <-- WIFEXITED
(gdb) bt
#0  sigchld_handler (signo=17) at process.c:6261
#1  <signal handler called>
#2  0x4031f784 in sigprocmask () from /lib/libc.so.6
#3  0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153
#4  0x0817a97d in Fstart_process (nargs=5, args=0xbfffea94) at process.c:1695
...
(gdb) fr 3
#3  0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153
2153      sigprocmask (SIG_SETMASK, &procmask, 0);

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: grep-use-null-device

[Stefan Monnier]

>>> `compilation-start' needs to check if the process is running
>>> before calling `process-send-eof':
>> 
>> That's odd.  AFAICT no blobking operation takes place between the
>> start-process and the process-send-eof, so the process-status should still
>> be `run' no matter how quickly the process exits (because Emacs shouldn't
>> process the SIGCHLD it receives until later).
>> 
>> What am I missing?

> The process exits during execution of create_process.  The gdb log below
> with a breakpoint on sigchld_handler demonstrates what really happens:

> Breakpoint 4, sigchld_handler (signo=17) at process.c:6249
> 6249              XSETINT (p->raw_status_low, u.i & 0xffff);
> (gdb) n
> 6250              XSETINT (p->raw_status_high, u.i >> 16);
> (gdb) n
> 6253              if ((WIFSIGNALED (w) || WIFEXITED (w))
> (gdb) n
> 6260                  FD_CLR (XINT (p->infd), &input_wait_mask);
> (gdb) n
> 6261                  FD_CLR (XINT (p->infd), &non_keyboard_wait_mask);
> (gdb) p w
> $1 = 512     <-- WIFEXITED
> (gdb) bt
> #0  sigchld_handler (signo=17) at process.c:6261
> #1  <signal handler called>
> #2  0x4031f784 in sigprocmask () from /lib/libc.so.6
> #3  0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153
> #4  0x0817a97d in Fstart_process (nargs=5, args=0xbfffea94) at process.c:1695
> ...
> (gdb) fr 3
> #3  0x0817af28 in create_process (process=141365940, new_argv=0xbfffe954, current_dir=140249731) at process.c:2153
> 2153      sigprocmask (SIG_SETMASK, &procmask, 0);

Oh, I now see that process-send-eof does:

  if (! NILP (XPROCESS (proc)->raw_status_low))
    update_status (XPROCESS (proc));

which basically copies the asynchronously updated proc->raw_status_* to the
synchronously updated proc->status.

Since this process status can change asynchronously, adding your test
for (eq (process-status proc) 'run) before calling process-send-eof doesn't
fix the bug but just narrows the window of the race condition because the
status can still change between the call to process-status and the call to
process-send-eof.

So I suggest the patch below instead,


        Stefan


--- compile.el	01 sep 2005 10:04:39 -0400	1.379
+++ compile.el	01 sep 2005 10:58:22 -0400	
@@ -1038,11 +1038,14 @@
 						       outbuf command))))
 	      ;; Make the buffer's mode line show process state.
 	      (setq mode-line-process '(":%s"))
-	      (when compilation-disable-input
-		(process-send-eof proc))
 	      (set-process-sentinel proc 'compilation-sentinel)
 	      (set-process-filter proc 'compilation-filter)
 	      (set-marker (process-mark proc) (point) outbuf)
+	      (when compilation-disable-input
+                (condition-case nil
+                    (process-send-eof proc)
+                  ;; The process may have exited already.
+                  (error nil)))
 	      (setq compilation-in-progress
 		    (cons proc compilation-in-progress)))
 	  ;; No asynchronous processes available.

Re: grep-use-null-device

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> `compilation-start' needs to check if the process is running
>>>> before calling `process-send-eof':
>>> 
>>> That's odd.  AFAICT no blobking operation takes place between the
>>> start-process and the process-send-eof, so the process-status should still
>>> be `run' no matter how quickly the process exits (because Emacs shouldn't
>>> process the SIGCHLD it receives until later).
>>> 
>>> What am I missing?
>
>> The process exits during execution of create_process.  The gdb log below
>> with a breakpoint on sigchld_handler demonstrates what really happens:
>
>> Breakpoint 4, sigchld_handler (signo=17) at process.c:6249

[...]

> Oh, I now see that process-send-eof does:
>
>   if (! NILP (XPROCESS (proc)->raw_status_low))
>     update_status (XPROCESS (proc));
>
> which basically copies the asynchronously updated proc->raw_status_* to the
> synchronously updated proc->status.
>
> Since this process status can change asynchronously, adding your test
> for (eq (process-status proc) 'run) before calling process-send-eof doesn't
> fix the bug but just narrows the window of the race condition because the
> status can still change between the call to process-status and the call to
> process-send-eof.
>
> So I suggest the patch below instead,

[...]

> +	      (when compilation-disable-input
> +                (condition-case nil
> +                    (process-send-eof proc)
> +                  ;; The process may have exited already.
> +                  (error nil)))
>  	      (setq compilation-in-progress
>  		    (cons proc compilation-in-progress)))
>  	  ;; No asynchronous processes available.

I think it is the wrong fix to just ignore an error which should not
occur in the first place.  Rather process-send-eof should be fixed not
to throw an error as long as the process is not considered dead from
Emacs' point of view.  That there is nobody to actually look at the
eof can't be considered a problem in asynchronous operations: the
consuming process can close down without waiting for an explicit eof.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: grep-use-null-device

[Stefan Monnier]

>> +	      (when compilation-disable-input
>> +                (condition-case nil
>> +                    (process-send-eof proc)
>> +                  ;; The process may have exited already.
>> +                  (error nil)))
>> (setq compilation-in-progress
>> (cons proc compilation-in-progress)))
>> ;; No asynchronous processes available.

> I think it is the wrong fix to just ignore an error which should not
> occur in the first place.  Rather process-send-eof should be fixed not
> to throw an error as long as the process is not considered dead from
> Emacs' point of view.  That there is nobody to actually look at the
> eof can't be considered a problem in asynchronous operations: the
> consuming process can close down without waiting for an explicit eof.

I agree it'd be the better thing to do.  But I have no patch to do that, so
unless someone else can provide a patch for it, my suggestion is a good
temporary workaround.


        Stefan

Re: grep-use-null-device

[Richard M. Stallman]

    I think it is the wrong fix to just ignore an error which should not
    occur in the first place.  Rather process-send-eof should be fixed not
    to throw an error as long as the process is not considered dead from
    Emacs' point of view.  That there is nobody to actually look at the
    eof can't be considered a problem in asynchronous operations: the
    consuming process can close down without waiting for an explicit eof.

That is a plausible argument, but I think the current way things work
is ok too.  This function is not used often, and catching the error
(when that's what you want) is not hard.

Re: "^D^H^H" in process output on Darwin

[Nozomu Ando]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> (It actually hangs on Mac OS X 10.1.5 and 10.2.8 if
> process-connection-type is set to t.  On Mac OS X 10.3.9 it seems not
> to hang.  Are there any other problems with vfork on Mac OS X 10.3,
> which is based on Darwin 7?)

A restriction of setsid(2) after vfork(2) may affect Emacs.

http://homepage.mac.com/nand/macosx/vfork_setsid.html

---
Nozomu Ando

Re: "^D^H^H" in process output on Darwin

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 13 Sep 2005 17:21:10 +0900, Nozomu Ando <nand@mac.com> said:

>> (It actually hangs on Mac OS X 10.1.5 and 10.2.8 if
>> process-connection-type is set to t.  On Mac OS X 10.3.9 it seems
>> not to hang.  Are there any other problems with vfork on Mac OS X
>> 10.3, which is based on Darwin 7?)

> A restriction of setsid(2) after vfork(2) may affect Emacs.

> http://homepage.mac.com/nand/macosx/vfork_setsid.html

Thanks for the info.  I'm not sure if it is a real issue for Emacs or
not, but maybe vfork should be avoided for now just to be on the safe
side.

I think I'll move the child_setup_tty call to before (v)fork only for
the case that the tty is not reopened in the child process.  Any
ideas/objections?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/process.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/process.c,v
retrieving revision 1.463
diff -c -r1.463 process.c
*** src/process.c	15 Aug 2005 08:44:53 -0000	1.463
--- src/process.c	17 Sep 2005 01:19:14 -0000
***************
*** 1793,1798 ****
--- 1793,1804 ----
  #endif
        if (forkin < 0)
  	report_file_error ("Opening pty", Qnil);
+ #if defined (RTU) || defined (UNIPLUS) || defined (DONT_REOPEN_PTY)
+       /* In the case that vfork is defined as fork, the parent process
+ 	 (Emacs) may send some data before the child process completes
+ 	 tty options setup.  So we setup tty before forking.  */
+       child_setup_tty (forkout);
+ #endif /* RTU or UNIPLUS or DONT_REOPEN_PTY */
  #else
        forkin = forkout = -1;
  #endif /* not USG, or USG_SUBTTY_WORKS */
***************
*** 2077,2084 ****
--- 2083,2092 ----
  #endif /* SIGCHLD */
  #endif /* !POSIX_SIGNALS */
  
+ #if !defined (RTU) && !defined (UNIPLUS) && !defined (DONT_REOPEN_PTY)
  	if (pty_flag)
  	  child_setup_tty (xforkout);
+ #endif /* not RTU and not UNIPLUS and not DONT_REOPEN_PTY */
  #ifdef WINDOWSNT
  	pid = child_setup (xforkin, xforkout, xforkout,
  			   new_argv, 1, current_dir);