Re: problem using call-process with grep

[Giorgos Keramidas]

        >     maybe what arrives at the application level is gamma(,)
        >     without backslashes
        >
        > Bingo!  Thank you, David.
        >
        > Don't know why I didn't see this before. I just need to use
        > "\\\\" to get \, as is usual with a Lisp string (which this
        > is). Sorry for wasting time.

        Uh, there is still something wrong here.  You wrote:

        >     >  (call-process "grep" nil
        >     >                (generate-new-buffer "Result")
        >     >                nil "epsilon\\($\\)" "foo")
        >     >

        This means that the string is 'epsilon\($\)', and call-process
        is supposed to pass this unmolested into grep.  So some other
        entity is removing a level of backslashes that shouldn't.  It is
        either call-process, or grep itself.

    Hm, you're right. It's as if we had to supply a regexp that would match the
    literal string `\('. The Lisp string to do that would be "\\\\(". I just
    re-read the doc for `grep' and `call-process'; neither mentions anything
    about this.

    To figure out whether this is specific to Cygwin `grep' or a property of
    `call-process', could someone else (e.g. on GNU/Linux) please try these:

    (call-process "/path/to/your/echo" nil t nil  "foo\\\\(bar\\\\)")

Using M-: the following expression evaluates to:

    (call-process "/bin/echo" nil t nil  "foo\\\\(bar\\\\)")
    => 0 (#o0, #x0)

In my Lisp interaction buffer the following is inserted:

    foo\\(bar\\)

Evaluating the following expression:

    (call-process "/path/to/your/echo" nil t nil  "foo\\(bar\\)")
    => 0 (#o0, #x0)

Results in the following line of text:

    foo\(bar\)

This is not GNU/Linux but FreeBSD/amd64, FWIW.  The results seem
to indicate that there is only one level of escaping here, the
one done by Lisp.