bug#727: compilation-disable-input

bug#727: compilation-disable-input

[Chong Yidong]

> I'm not sure what this is intended to do.  Sending just one EOF  
> character to a process creates one EOF if many conditions are met.   
> But a second read from the same pty will continue to look for input.
>
> The following code:
> 	      (when compilation-disable-input
>                 (condition-case nil
>                     (process-send-eof proc)
>                   ;; The process may have exited already.
>                   (error nil)))
>
> Causes my grep buffer to start with a ^D (the EOF character that  
> process-send-eof sends).  This goofs up the parsing of the lines.

I can't reproduce this (I don't see any ^D character in grep buffers).
Could you send a recipe for reproducing this bug, as well as your system
specs?

bug#727: compilation-disable-input

[Stefan Monnier]

>> I'm not sure what this is intended to do.  Sending just one EOF  
>> character to a process creates one EOF if many conditions are met.   
>> But a second read from the same pty will continue to look for input.
>> 
>> The following code:
>> (when compilation-disable-input
>> (condition-case nil
>> (process-send-eof proc)
>> ;; The process may have exited already.
>> (error nil)))
>> 
>> Causes my grep buffer to start with a ^D (the EOF character that  
>> process-send-eof sends).  This goofs up the parsing of the lines.

> I can't reproduce this (I don't see any ^D character in grep buffers).
> Could you send a recipe for reproducing this bug, as well as your system
> specs?

I remember seeing exactly these kinds of ^D under Mac OS X where
process-send-eof causes them (either for pipes or for ttys, can't
remember which).

I even added a workaround for this problem in pcvs.el's
cvs-parse-process:

  (when (eq system-type 'darwin)
    ;; Fixup the ^D^H^H inserted at beginning of buffer sometimes on MacOSX
    ;; because of the call to `process-send-eof'.
    (save-excursion
      (goto-char (point-min))
      (while (re-search-forward "^\\^D\b+" nil t)
	(let ((inhibit-read-only t))
	  (delete-region (match-beginning 0) (match-end 0))))))

Not sure if it's related.


        Stefan

bug#727: compilation-disable-input

[Andrew Hyatt]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> I'm not sure what this is intended to do.  Sending just one EOF  
>>> character to a process creates one EOF if many conditions are met.   
>>> But a second read from the same pty will continue to look for input.
>>> 
>>> The following code:
>>> (when compilation-disable-input
>>> (condition-case nil
>>> (process-send-eof proc)
>>> ;; The process may have exited already.
>>> (error nil)))
>>> 
>>> Causes my grep buffer to start with a ^D (the EOF character that  
>>> process-send-eof sends).  This goofs up the parsing of the lines.
>
>> I can't reproduce this (I don't see any ^D character in grep buffers).
>> Could you send a recipe for reproducing this bug, as well as your system
>> specs?
>
> I remember seeing exactly these kinds of ^D under Mac OS X where
> process-send-eof causes them (either for pipes or for ttys, can't
> remember which).
>
> I even added a workaround for this problem in pcvs.el's
> cvs-parse-process:
>
>   (when (eq system-type 'darwin)
>     ;; Fixup the ^D^H^H inserted at beginning of buffer sometimes on MacOSX
>     ;; because of the call to `process-send-eof'.
>     (save-excursion
>       (goto-char (point-min))
>       (while (re-search-forward "^\\^D\b+" nil t)
> 	(let ((inhibit-read-only t))
> 	  (delete-region (match-beginning 0) (match-end 0))))))
>
> Not sure if it's related.
>
>
>         Stefan

I can't reproduce this in Emacs 25, on Mac OS X (although, as Yidong
noted, we don't have clear reproducible steps). Due to all that, and as
the original author hasn't replied in the last 7 years. I'm closing this
as unreproducible, but please re-open if it still exists.

bug#727: compilation-disable-input

[Perry Smith]

I'm not sure what this is intended to do.  Sending just one EOF  
character to a process creates one EOF if many conditions are met.   
But a second read from the same pty will continue to look for input.

The following code:
	      (when compilation-disable-input
                 (condition-case nil
                     (process-send-eof proc)
                   ;; The process may have exited already.
                   (error nil)))

Causes my grep buffer to start with a ^D (the EOF character that  
process-send-eof sends).  This goofs up the parsing of the lines.

If you really do not want input, you need to close stdin.  This could  
be done in various ways but this is not the way to do it.

Perry Smith
pedzan@austin.ibm.com