GNU bug report logs - #6784
24.0.50; cmdproxy incosistency with command pathnames

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6784 in the body.
You can then email your comments to 6784 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 17:56:52 +0200

A command path name that contains slashes (instead of backslashes) will
work fine with cmdproxy as far as it doesn't require to be executed
through a shell. Otherwise only backslashes work. Example:

cmdproxy.exe -c "c:/foo/bar.exe"

which executes bar.exe through CreateProces, works fine, but

cmdproxy.exe -c "c:/foo/bar.exe | zoo.exe"

which invokes the shell for executing the command, fails with an error
message that comes from cmd.exe and that says "c:" is not recognized as
a command.

OTOH,

cmdproxy.exe -c "c:\foo\bar.exe | zoo.exe"

works fine.

cmd.exe has no problem with commands that uses the slash as directory
separator, as this works OK:

cmd /c c:/foo/bar.exe

so the problem must be in cmdproxy, which probably splits the command as

"c:" "/foo/bar.exe"

and passes it as separate arguments to the shell.

Although this bug possibly is not hard to fix, maybe we should consider
the larger scenario: is it worth the trouble having two separate
execution paths on cmdproxy? Inconsistencies like this among the two
separate ways of executing commands may arise on the future, confusing
the users. Maybe we should remove the CreateProcess method and do
everything through the underlying shell.

Message #8 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 20:21:13 +0300

> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Date: Tue, 03 Aug 2010 17:56:52 +0200
> Cc: 
> 
> A command path name that contains slashes (instead of backslashes) will
> work fine with cmdproxy as far as it doesn't require to be executed
> through a shell. Otherwise only backslashes work. Example:
> 
> cmdproxy.exe -c "c:/foo/bar.exe"
> 
> which executes bar.exe through CreateProces, works fine, but
> 
> cmdproxy.exe -c "c:/foo/bar.exe | zoo.exe"
> 
> which invokes the shell for executing the command, fails with an error
> message that comes from cmd.exe and that says "c:" is not recognized as
> a command.

Please show the full recipe to reproduce this problem.  You don't
invoke cmdproxy from the command line, do you?

> Maybe we should remove the CreateProcess method and do everything
> through the underlying shell.

That's not a good idea if the shell is command.com, for sure.

For cmd.exe, the problem is a lesser one, but it still exists; e.g.,
cmd.exe is limited to 4K long commands, while CreateProcess can handle
32K.

Message #11 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 19:52:22 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Please show the full recipe to reproduce this problem.  You don't
> invoke cmdproxy from the command line, do you?

Put this on .emacs, or start with emacs -Q and evaluate it:

(setq find-program "c:/apps/gnuwin32/bin/find.exe")

Now, do a rgrep.

There is no problem if you use the backslash as the path separator.

>> Maybe we should remove the CreateProcess method and do everything
>> through the underlying shell.
>
> That's not a good idea if the shell is command.com, for sure.

Okay.

> For cmd.exe, the problem is a lesser one, but it still exists; e.g.,
> cmd.exe is limited to 4K long commands, while CreateProcess can handle
> 32K.

That's one more incosistency: a long command works fine, then you put
that command as part of a pipe chain and it stops working. I guess the
current cmdproxy approach is the lesser evil.

Message #14 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 21:15:30 +0300

> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Cc: 6784 <at> debbugs.gnu.org
> Date: Tue, 03 Aug 2010 19:52:22 +0200
> 
> > For cmd.exe, the problem is a lesser one, but it still exists; e.g.,
> > cmd.exe is limited to 4K long commands, while CreateProcess can handle
> > 32K.
> 
> That's one more incosistency: a long command works fine, then you put
> that command as part of a pipe chain and it stops working.

Perhaps we should bite the bullet and implement redirection and pipes
within cmdproxy.

Message #17 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 21:19:23 +0300

Óscar Fuentes wrote:

> That's one more incosistency: a long command works fine, then you put
> that command as part of a pipe chain and it stops working. I guess the
> current cmdproxy approach is the lesser evil.

It's a CreateProcess() (in cmdproxy.c) _valid_ path requirement/problem; 
valid path/directory separator is (should be) '\':

http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

(only File I/O API converts '/' to '\')

p.s. cmd.exe /c accepts both variants.

Message #20 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
Cc: ofv <at> wanadoo.es, 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 22:28:22 +0300

> From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
> Cc: 6784 <at> debbugs.gnu.org
> 
> Óscar Fuentes wrote:
> 
> > That's one more incosistency: a long command works fine, then you put
> > that command as part of a pipe chain and it stops working. I guess the
> > current cmdproxy approach is the lesser evil.
> 
> It's a CreateProcess() (in cmdproxy.c) _valid_ path requirement/problem; 
> valid path/directory separator is (should be) '\':

But the name of the shell, which is the only file name CreateProcess
should care about in this case, _is_ converted to use backslashes:

      progname = getenv ("COMSPEC");
      if (!progname)
	fail ("error: COMSPEC is not set\n");

      canon_filename (progname);

And canon_filename is

    char *
    canon_filename (char *fname)
    {
      char *p = fname;

      while (*p)
	{
	  if (*p == '/')
	    *p = '\\';
	  p++;
	}

      return fname;
    }

Message #23 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 23:15:30 +0300

Eli Zaretskii wrote:
>> From: Laimonas Vėbra<laimonas.vebra <at> gmail.com>
>> Cc: 6784 <at> debbugs.gnu.org
>>
>> Óscar Fuentes wrote:
>>
>>> That's one more incosistency: a long command works fine, then you put
>>> that command as part of a pipe chain and it stops working. I guess the
>>> current cmdproxy approach is the lesser evil.
>>
>> It's a CreateProcess() (in cmdproxy.c) _valid_ path requirement/problem;
>> valid path/directory separator is (should be) '\':
>
> But the name of the shell, which is the only file name CreateProcess
> should care about in this case, _is_ converted to use backslashes:

The problem is poor CreateProcess() description and some flawless aspects.
Why do we have to call CreateProcess like this:

 rv = CreateProcess (progname, cmdline, &sec_attrs, NULL, TRUE,
			0, envblock, dir, &si, &child);

where progname is 'cmd.exe' and cmdline is 'cmd.exe /c command'

Somewhere i read, that this way it just works (with less problems).

The problem doesn't occur, when we call CreateProcess() like
this:
CreateProcess ('C:\cygwin\bin\ls.exe', 'C:/cygwin/bin/ls.exe'...)

That's actually the case when we are not invoking a shell (command 
without pipe or redirection), e.g.:
M-x grep
c:/cygwin/bin/ls

Then progname gets correctly backslashed by:
 if (!get_next_token (path, &args))
	  canon_filename (path);
	  progname = make_absolute (path);

My guess is that in this case CreateProcess() takes correctly 
backslashed progname (LPCTSTR lpApplicationName),
as the executable module name (program name), _ignores_ first token of 
cmdline (LPTSTR lpCommandLine) as it is internally treated to be the 
same executable module name (although with wrong slashes) and 
takes/passes remaining tokens of cmdline as command line args of progname.



Actual bug problem arises/occurs, then we are invoking a shell (e.g. 
c:/cygwin/bin/ls | grep foo); then CreateProcess() gets likes this:

CreateProcess('C:\WINDOWS\system32\cmd.exe', 
'"C:\WINDOWS\system32\cmd.exe" /c c:/cygwin/bin/ls | grep foo'...)

I guess, that CreateProcess(), in this case, internally processes 
command line args, i.e. program names/paths ('c:/cygwin/bin/ls', 
'grep'), that it passes to cmd.exe and because command name/path is not 
correctly/appropriately constructed (should be backslashed), it (chain 
CreateProcess()->cmd.exe) fails.

Message #26 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 23:57:16 +0300

Laimonas Vėbra wrote:

> I guess, that CreateProcess(), in this case, internally processes
> command line args, i.e. program names/paths ('c:/cygwin/bin/ls',
> 'grep'), that it passes to cmd.exe and because command name/path is not
> correctly/appropriately constructed (should be backslashed), it (chain
> CreateProcess()->cmd.exe) fails.

Wrong. Actually it's cmd.exe that fails if command string contains pipe 
and (subsequent slashed, not backslashed) program names are not quoted.

Works:
cmd.exe /c c:/cygwin/bin/ls | grep foo
cmd.exe /c c:/cygwin/bin/ls | C:\cygwin\bin\grep foo
cmd.exe /c c:/cygwin/bin/ls | "C:/cygwin/bin/grep" foo
cmd.exe /c "c:/cygwin/bin/ls" | "C:/cygwin/bin/grep" foo

Fails:
cmd.exe /c c:/cygwin/bin/ls | C:/cygwin/bin/grep foo



So it could be fixed in two ways:
1. using windows path naming rules when calling CreateProcess()
2. quoting program names (all or if it contains slashes '/', i.e. is not 
backslashed) args when calling CreateProcess()

I'm not sure which one would be easier and more error prone.

Message #29 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Wed, 04 Aug 2010 06:08:25 +0300

> Date: Tue, 03 Aug 2010 23:57:16 +0300
> From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
> CC: 6784 <at> debbugs.gnu.org
> 
> Laimonas Vėbra wrote:
> 
> > I guess, that CreateProcess(), in this case, internally processes
> > command line args, i.e. program names/paths ('c:/cygwin/bin/ls',
> > 'grep'), that it passes to cmd.exe and because command name/path is not
> > correctly/appropriately constructed (should be backslashed), it (chain
> > CreateProcess()->cmd.exe) fails.
> 
> Wrong. Actually it's cmd.exe that fails if command string contains pipe 
> and (subsequent slashed, not backslashed) program names are not quoted.
> 
> Works:
> cmd.exe /c c:/cygwin/bin/ls | grep foo
> cmd.exe /c c:/cygwin/bin/ls | C:\cygwin\bin\grep foo
> cmd.exe /c c:/cygwin/bin/ls | "C:/cygwin/bin/grep" foo
> cmd.exe /c "c:/cygwin/bin/ls" | "C:/cygwin/bin/grep" foo
> 
> Fails:
> cmd.exe /c c:/cygwin/bin/ls | C:/cygwin/bin/grep foo

In the case in point, the problem was with the executable _before_
the pipe.

Message #32 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Wed, 04 Aug 2010 13:28:58 +0300

Eli Zaretskii wrote:

>> Laimonas Vėbra wrote:
>>
>>> <...>
>>
>> Works:
>> cmd.exe /c c:/cygwin/bin/ls | grep foo
>> cmd.exe /c c:/cygwin/bin/ls | C:\cygwin\bin\grep foo
>> cmd.exe /c c:/cygwin/bin/ls | "C:/cygwin/bin/grep" foo
>> cmd.exe /c "c:/cygwin/bin/ls" | "C:/cygwin/bin/grep" foo
>>
>> Fails:
>> cmd.exe /c c:/cygwin/bin/ls | C:/cygwin/bin/grep foo


> In the case in point, the problem was with the executable _before_
> the pipe.

Or with subsequent _slashed_ _and_ _unquoted_ executable(s).
Quote whole command line (with slashed programs/paths single quoted):

M-x shell-command
""c:/cygwin/bin/ls" | grep foo"
M-x shell-command
""c:/cygwin/bin/ls" | "c:/cygwin/bin/grep" foo"


or:

cmdproxy -c """c:/cygwin/bin/ls" | grep o""
cmdproxy -c """c:/cygwin/bin/ls" | "c:/cygwin/bin/grep" o""

and it _works_.

cmd /?:

If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:

    1.  If all of the following conditions are met, then quote 
characters on the command line are preserved:

        - no /S switch
        - exactly two quote characters
        - no special characters between the two quote characters,
          where special is one of: &<>()@^|
        - there are one or more whitespace characters between the
          the two quote characters
        - the string between the two quote characters is the name
          of an executable file.

    2.  Otherwise, old behavior is to see if the first character is
        a quote character and if so, strip the leading character and
        remove the last quote character on the command line, preserving
        any text after the last quote character.

Message #35 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, 6784 <at> debbugs.gnu.org
Subject: Re: 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,
> 	RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,T_DKIM_INVALID autolearn=ham version=3.3.1
> Date: Wed, 5 Jan 2011 17:43:15 -0500
> From: Sam Steingold <sds <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 7785 <at> debbugs.gnu.org
> 
> On Wed, Jan 5, 2011 at 5:29 PM, Óscar Fuentes <ofv <at> wanadoo.es> 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.

Comments?

Message #38 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Sam Steingold <sds <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, 6784 <at> debbugs.gnu.org
Subject: Re: bug#7785: rgrep is broken on woe32
Date: Thu, 6 Jan 2011 10:25:42 -0500

On Thu, Jan 6, 2011 at 7:09 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 5 Jan 2011 17:43:15 -0500
>> From: Sam Steingold <sds <at> gnu.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 7785 <at> debbugs.gnu.org
>>
>> On Wed, Jan 5, 2011 at 5:29 PM, Óscar Fuentes <ofv <at> wanadoo.es> wrote:
>> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784
>> definitely. is that bug going to be fixed?
> ... Would that be an okay solution?

any solution which fixes my problem is OK :-)

> Comments?

the problems you describe seem to boil down to re-implementing cmd in cmdproxy.
this begs the question, why does emacs have to provide cmdproxy?
why not use cmd provided by windows?

-- 
Sam Steingold <http://sds.podval.org>

Message #41 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, 6784 <at> debbugs.gnu.org
Subject: Re: bug#7785: rgrep is broken on woe32
Date: Thu, 06 Jan 2011 11:07:13 -0500

> Date: Thu, 6 Jan 2011 10:25:42 -0500
> From: Sam Steingold <sds <at> gnu.org>
> Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, 6784 <at> debbugs.gnu.org
> 
> the problems you describe seem to boil down to re-implementing cmd in cmdproxy.
> this begs the question, why does emacs have to provide cmdproxy?
> why not use cmd provided by windows?

cmdproxy does not reimplement cmd.  It is really just a proxy to cmd,
designed to fix a few idiosyncrasies, and that's it.  When cmdproxy
concludes that a shell is needed, it invokes cmd (or some other
shell).  This part of the commentary at the beginning of cmdproxy.c
should tell the story:

   Accepts subset of Unix sh(1) command-line options, for compatibility
   with elisp code written for Unix.  When possible, executes external
   programs directly (a common use of /bin/sh by Emacs), otherwise
   invokes the user-specified command processor to handle built-in shell
   commands, batch files and interactive mode.

   The main function is simply to process the "-c string" option in the
   way /bin/sh does, since the standard Windows command shells use the
   convention that everything after "/c" (the Windows equivalent of
   "-c") is the input string.

Message #44 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, Sam Steingold <sds <at> gnu.org>,
	6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: bug#7785: rgrep is broken on woe32
Date: Sat, 08 Jan 2011 16:00:43 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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?

I think this is an acceptable solution, and agree that changing cmdproxy
to handle this intelligently sounds like a nightmare.

> The disadvantage is, of course, that similar solutions will have to be
> implemented for each Emacs command that launches a shell pipeline.

Let's just fix these individually as the problems are reported.

Message #49 received at 6784-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>,
	Michael Albinus <michael.albinus <at> gmx.de>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, sds <at> gnu.org,
	6784-done <at> debbugs.gnu.org
Subject: Re: bug#6784: bug#7785: rgrep is broken on woe32
Date: Sun, 09 Jan 2011 19:59:56 +0200

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: Sam Steingold <sds <at> gnu.org>, 7785 <at> debbugs.gnu.org, 6784 <at> debbugs.gnu.org
> Date: Sat, 08 Jan 2011 16:00:43 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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?
> 
> I think this is an acceptable solution, and agree that changing cmdproxy
> to handle this intelligently sounds like a nightmare.

Okay, fixed in grep.el (revno 100367 on the emacs-23 branch).

> > The disadvantage is, of course, that similar solutions will have to be
> > implemented for each Emacs command that launches a shell pipeline.
> 
> Let's just fix these individually as the problems are reported.

I found only 2 more instances of this that need to be fixed.  One of
them is in jka-compr.el, where it calls `dd' in a pipe.  I fixed that
one.  The other one is in tramp.el, which uses shell pipelines a lot;
however, the only ones that need to be fixed are those that invoke
_local_ programs, not remote programs, as the latter will not be on a
Windows machine.  Michael, could you please take care of that (on the
emacs-23 branch)?  I gather that you have your master repository, so
doing it from there would be less hassle for you, and you know the
semantics of each pipeline better than I do.  Thanks.

Message #50 received at 6784-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	sds <at> gnu.org, 6784-done <at> debbugs.gnu.org
Subject: Re: bug#6784: bug#7785: rgrep is broken on woe32
Date: Sun, 09 Jan 2011 20:56:48 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Michael, could you please take care of that (on the emacs-23 branch)?
> I gather that you have your master repository, so doing it from there
> would be less hassle for you, and you know the semantics of each
> pipeline better than I do.  Thanks.

I'll do next days.

Best regards, Michael.

Message #53 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ofv <at> wanadoo.es, 7785 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	sds <at> gnu.org, 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: bug#7785: rgrep is broken on woe32
Date: Mon, 10 Jan 2011 21:57:52 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Michael, could you please take care of that (on the emacs-23 branch)?
> I gather that you have your master repository, so doing it from there
> would be less hassle for you, and you know the semantics of each
> pipeline better than I do.  Thanks.

I've found 3 places to patch in tramp.el, fixed in the emacs-23
branch. Under GNU/Linux I could not observe any regression. However, I
cannot test under Windows - could somebody, please, check it with a new
build? It shall be sufficient to open a large (>10kB) remote file,
using the plink method.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.