grep /dev/null

grep /dev/null

[Karl Chen]

I often when using `grep' type a regexp but forget to type a file
glob.  This leads to slightly annoying behavior: it sits waiting
for input on stdin that never arrives.  Once you realize that it's
not searching you have to kill it manually.

I think it would be useful if such grep invocations terminate
immediately.  One easy way would be to always append " /dev/null
(i.e. grep-use-null-device) or " </dev/null".  In fact, it might
be a good idea to add an optional flag to start-process so that
`compilation-start' can reliably pipe from null by default.


-- 
Karl 2005-02-02 21:11

Re: grep /dev/null

[Kevin Rodgers]

Karl Chen wrote:
 > I think it would be useful if such grep invocations terminate
 > immediately.  One easy way would be to always append " /dev/null
 > (i.e. grep-use-null-device) or " </dev/null".  In fact, it might
 > be a good idea to add an optional flag to start-process so that
 > `compilation-start' can reliably pipe from null by default.

I don't understand: `M-x grep' does append null-device to the command
line (unless it's been set to nil).

With respect to compile, I posted a patch back in October 1996 that
defines a new variable (compile-disable-input) and sends an EOF to the
compilation process if it is non-nil (which it is, by default).  I also
posted a compilation-mode-hook function (compile-enable-input) that
allows the user to run compilations that require input by emulating
comint-mode in the *compilation* buffer.

-- 
Kevin Rodgers

Re: grep /dev/null

[Andreas Schwab]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Karl Chen wrote:
>> I think it would be useful if such grep invocations terminate
>> immediately.  One easy way would be to always append " /dev/null
>> (i.e. grep-use-null-device) or " </dev/null".  In fact, it might
>> be a good idea to add an optional flag to start-process so that
>> `compilation-start' can reliably pipe from null by default.
>
> I don't understand: `M-x grep' does append null-device to the command
> line (unless it's been set to nil).

Unless grep understands the -H option.

Andreas.

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

Re: grep /dev/null

[Richard Stallman]

    With respect to compile, I posted a patch back in October 1996 that
    defines a new variable (compile-disable-input) and sends an EOF to the
    compilation process if it is non-nil (which it is, by default).  I also
    posted a compilation-mode-hook function (compile-enable-input) that
    allows the user to run compilations that require input by emulating
    comint-mode in the *compilation* buffer.

Could you adapt these to the current version of compile.el?

Re: grep /dev/null

[Kevin Rodgers]

Richard Stallman wrote:
 >     With respect to compile, I posted a patch back in October 1996 that
 >     defines a new variable (compile-disable-input) and sends an EOF 
to the
 >     compilation process if it is non-nil (which it is, by default). 
I also
 >     posted a compilation-mode-hook function (compile-enable-input) that
 >     allows the user to run compilations that require input by emulating
 >     comint-mode in the *compilation* buffer.
 >
 > Could you adapt these to the current version of compile.el?

Sure, here's the first part:


2005-02-09  Kevin Rodgers  <ihs_4664@yahoo.com>

	* progmodes/compile.el (compilation-disable-input): New option.
	(compilation-start): If it's non-nil, send an EOF to the process.


*** compile.el~	Wed Feb  9 09:41:47 2005
--- compile.el	Wed Feb  9 09:56:59 2005
***************
*** 860,865 ****
--- 860,873 ----
       (compilation-start command nil name-function highlight-regexp)))
   (make-obsolete 'compile-internal 'compilation-start)

+ (defcustom compilation-disable-input t
+   "*If non-nil, send end-of-file as compilation process input.
+ This only affects platforms that support asynchronous processes (see
+ start-process); synchronous compilation processes never accept input."
+   :type 'boolean
+   :group 'compilation
+   :version "22.1")
+
   (defun compilation-start (command &optional mode name-function 
highlight-regexp)
     "Run compilation command COMMAND (low level interface).
   If COMMAND starts with a cd command, that becomes the 
`default-directory'.
***************
*** 974,979 ****
--- 982,989 ----
   						       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)

-- 
Kevin Rodgers

Re: grep /dev/null

[Richard Stallman]

This change looks reasonable to me.  Does anyone see a problem with it?

    2005-02-09  Kevin Rodgers  <ihs_4664@yahoo.com>

	    * progmodes/compile.el (compilation-disable-input): New option.
	    (compilation-start): If it's non-nil, send an EOF to the process.

However, the code in compilation-start should test the argument COMINT.

This led me to note something confusing in the doc string of
compilation-start.


      "Compile the program including the current buffer.  Default: run `make'.
    Runs COMMAND, a shell command, in a separate process asynchronously
    with output going to the buffer `*compilation*'.

    If optional second arg COMINT is t the buffer will be in Comint mode with
    `compilation-shell-minor-mode'.

    You can then use the command \\[next-error] to find the next error message
    and move to the source code that caused it.


The third paragraph appears to relate only to the case where COMINT is t.
But I think it actually applies regardless of the value of COMINT.
Am I missing something?