[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6784: bug#7785: rgrep is broken on woe32

From: Eli Zaretskii
Subject: bug#6784: bug#7785: rgrep is broken on woe32
Date: Thu, 06 Jan 2011 07:09:10 -0500

> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
> version=3.3.1
> Date: Wed, 5 Jan 2011 17:43:15 -0500
> From: Sam Steingold <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden
> On Wed, Jan 5, 2011 at 5:29 PM, Óscar Fuentes <address@hidden> wrote:
> >
> > Maybe it is related to this:
> >
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784
> >
> definitely. is that bug going to be fixed?

The discussions in that bug report concluded that the program file
name after the pipe needs to be quoted, in order for it to work with
file names that use forward- and back-slashes alike.  I can solve that
problem for rgrep (and for other similar commands) by tweaking the
templates used by grep.el, so as to quote the %s after the pipe
character `|'.  Would that be an okay solution?

The other alternative I thought about, to fix this inside cmdproxy,
has a disadvantage that the command semantics cannot be easily
determined at such a low level.  The first word after the `|' might
not always be a name of an executable file, or it could already be
quoted in some ingenious ways, or it might be a part of a quoted pipe
that is intended to survive unaltered, to be passed to some other
program and not executed as a shell pipeline.  Even if we teach
cmdproxy about all of these use-cases and write/debug code to handle
each and every one of them, we will certainly miss some.  We will also
force this quoting on commands typed interactively, so users lose the
fire escape they can use now to quote or not to quote.

As a general principle, I believe that the level which conses the
command line is where such decision should be made, because that level
surely knows the context, and knows _exactly_ where are the parts that
need quoting.

The disadvantage is, of course, that similar solutions will have to be
implemented for each Emacs command that launches a shell pipeline.
But I don't believe there are many of those.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]