RE: grep command doc - point out that you can chain now

[Drew Adams]

     >     Probably because you knew it didn't work in the past.
     >
     > Yes, I said that myself.

    You predicted Richard's reponse?

Oops - I thought you were quoting me; my bad. I thought I said that one
reason I didn't expect it was that I knew it didn't work in the past.

     > And, I added, also because what you type is apparently not
     > the arguments to the Unix/GNU-Linux `grep' command, but something
     > possibly much richer. Even if someone were not used to Emacs 20
     > `grep' behavior, if s?he were used to the Unix/GNU-Linux `grep'
     > command, then s?he would expect to be inputting
     > just the `grep' args, no?

    Grep uses start-process just like shell-command.  You saw it as
    natural to use the latter with a pipe so I'm surprised that you
    feel it needs explaining for grep.

You know something? I'm learning more and more here. I was about to write
that I wouldn't naturally expect just any old Unix/GNU-Linux command used in
Emacs to accept more than the args defined for that command. Looking for
"proof", I tried `M-x man RET grep | grep grep'. My intention was to show
that `man', another Unix command, would barf and not accept the piping.

Well... I was wrong. That works too! And that one works in Emacs 20 too.

I don't know; is this obvious to others? It really wasn't to me.

Fun. And I wonder now if this shouldn't be documented generally, because
it's apparently not an Emacs `grep' thing, but it is, as you say, because
`start-process' is used.

I'd say that this should perhaps be made more clear in the Emacs-Lisp doc
for `start-process'. That doc does point out that `start-process' starts an
asynchronous process, and it says that whatever you give it as &rest args
are treated like command-line args, but, though I've read that before and
used `start-process' several times, I never interpreted "command-line
arguments for the program" (e.g. grep) to mean whatever might be on the
command line, including pipes (and redirection etc., presumably).

How about rewording this, to emphasize the generality (a shell command line
passed to the process) and de-emphasize "arguments" to the program? I guess
I wasn't thinking well enough about processes interpreting the command line;
I don't know if others might think similarly.

And, because Emacs users will not know about it, and because `grep', in
particular, is so useful when chained, I still think the grep-piping use
pattern is worth pointing out in the Emacs `grep' doc.

    Grep failed in the past because grep-use-null-device was
    automatically t (or more accurately "/dev/null" was always appended
    to the end of the command)

I see.

    By saying that I would expect it to work,
    I mean I can't see why it wouldn't.
    Could you see a reason?

No, now that I understand it, I understand it (I think) ;-).

    M-x grep says:  Run grep (like this): grep -nH -e
    not Run grep (with the following arguments): -nH -e

Yes, I noticed that prompt change, but the subtlety didn't sink in. It's not
just running `grep' with those options, however. It's starting an
asynchronous process and passing `grep -nH -e...' to it. That's not really
the same thing as executing `grep -hH -e <some grep args>', it seems to me.

    Behaviour depends on the version of grep and the value of
    grep-command but ultimately the value of grep-use-null-device.
    It has to do with the fact that without "-H" grep doesn't
    output the filename if only one is given
    in the input (hence the dummy extra: /dev/null).  I don't which versions
    of grep have "-H" or when it was added to GNU/Linux.

I see. Good to know. I'm not sure how much of this info is worth
documenting, but I'm convinced some of it is:

1. Explain better that `start-process' accepts a shell command line, not
just arguments for the command.

2. Explain that (depending on your version of grep), you might be able to
chain grep commands.

Very enlightening - thx.