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

Previous Next

Full log

View this message in rfc822 format

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: bug#6784: 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.

Previous Next

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