* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS @ 2010-07-20 3:49 Óscar Fuentes 2010-07-20 12:57 ` Juanma Barranquero ` (3 more replies) 0 siblings, 4 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-07-20 3:49 UTC (permalink / raw) To: 6674 On Windows, when find-program points to a GNU-compatible `find' executable, grep-find-use-xargs is assigned the symbol 'gnu. The consequence of this is that `rgrep' ends building a command that contains a pipe: find <args> | xargs -0 grep <args> This ends with `find' reporting confusing errors about wrong arguments. An extra test is added to the assigment of grep-find-use-xargs to force the value 'exec on Windows and MS-DOS. 2010-07-20 Óscar Fuentes <ofv@wanadoo.es> * progmodes/grep.el: (grep-compute-defaults): always assign 'exec to grep-find-use-xargs on Windows and MS-DOS. === modified file 'lisp/progmodes/grep.el' *** lisp/progmodes/grep.el 2010-05-21 20:43:04 +0000 --- lisp/progmodes/grep.el 2010-07-20 03:42:21 +0000 *************** Set up `compilation-exit-message-functio *** 552,557 **** --- 552,560 ---- (unless grep-find-use-xargs (setq grep-find-use-xargs (cond + ;; We don't want a shell pipe on those systems: + ((or (eq system-type 'windows-nt) (eq system-type 'ms-dos)) + 'exec) ((and (grep-probe find-program `(nil nil nil ,null-device "-print0")) (grep-probe xargs-program `(nil nil nil "-0" "-e" "echo"))) ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 3:49 bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS Óscar Fuentes @ 2010-07-20 12:57 ` Juanma Barranquero 2010-07-20 13:39 ` Óscar Fuentes 2010-07-20 16:46 ` bug#6674: PATCH: " Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2010-07-20 12:57 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 6674 2010/7/20 Óscar Fuentes <ofv@wanadoo.es>: > On Windows, when find-program points to a GNU-compatible `find' > executable, grep-find-use-xargs is assigned the symbol 'gnu. The > consequence of this is that `rgrep' ends building a command that > contains a pipe: find <args> | xargs -0 grep <args> This ends with > `find' reporting confusing errors about wrong arguments. Yes, I get c:/gnu/bin/find.exe: invalid predicate `-nam' but the very same command works from the command line. So the right thing would be to fix how rgrep invokes the command on Windows, wouldn't it? Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 12:57 ` Juanma Barranquero @ 2010-07-20 13:39 ` Óscar Fuentes 2010-07-20 14:24 ` Óscar Fuentes 0 siblings, 1 reply; 36+ messages in thread From: Óscar Fuentes @ 2010-07-20 13:39 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 6674 Juanma Barranquero <lekktu@gmail.com> writes: > Yes, I get > > c:/gnu/bin/find.exe: invalid predicate `-nam' This is, most likely, a command-line lenght issue. Do C-u M-x rgrep and enter the same parameters. When Emacs displays the command to be executed on the minibuffer, insert an extra space between some of the first parameters. Then the problem becomes c:/gnu/bin/find.exe: invalid predicate `-na' > but the very same command works from the command line. So the right > thing would be to fix how rgrep invokes the command on Windows, > wouldn't it? Agreed. That's a symptom of a more general problem. I have no idea of what's going on, because if the pipe is not used the command line for `find' is similar on length and the problem doesn't happen. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 13:39 ` Óscar Fuentes @ 2010-07-20 14:24 ` Óscar Fuentes 2010-07-20 15:18 ` Juanma Barranquero ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-07-20 14:24 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 6674 Óscar Fuentes <ofv@wanadoo.es> writes: > Agreed. That's a symptom of a more general problem. I have no idea of > what's going on, because if the pipe is not used the command line for > `find' is similar on length and the problem doesn't happen. Pasting the command on cmd.exe works fine (after replacing / with \ on the path to `find.exe') Executing cmd.exe -c <command> from cmd.exe fails on a similar way: "CS" -o -path "*" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable. This looks like a can of worms. Can we apply the patch on the original post, so `rgrep' is usable on Windows with the minimal fuss? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 14:24 ` Óscar Fuentes @ 2010-07-20 15:18 ` Juanma Barranquero 2010-07-20 16:56 ` Eli Zaretskii 2010-07-20 17:28 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2010-07-20 15:18 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 6674 On Tue, Jul 20, 2010 at 16:24, Óscar Fuentes <ofv@wanadoo.es> wrote: > This looks like a can of worms. Can we apply the patch on the original > post, so `rgrep' is usable on Windows with the minimal fuss? Let's wait for other people's comments, but if you commit that fix, at the very least I'd suggest adding a big comment stating clearly that this is a workaround and the underlying bug is neither well understood nor fixed. Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 14:24 ` Óscar Fuentes 2010-07-20 15:18 ` Juanma Barranquero @ 2010-07-20 16:56 ` Eli Zaretskii 2010-07-20 17:28 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-07-20 16:56 UTC (permalink / raw) To: Óscar Fuentes; +Cc: lekktu, 6674 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Tue, 20 Jul 2010 16:24:59 +0200 > Cc: 6674@debbugs.gnu.org > > Óscar Fuentes <ofv@wanadoo.es> writes: > > > Agreed. That's a symptom of a more general problem. I have no idea of > > what's going on, because if the pipe is not used the command line for > > `find' is similar on length and the problem doesn't happen. > > Pasting the command on cmd.exe works fine (after replacing / with \ on > the path to `find.exe') > > Executing > > cmd.exe -c <command> > > from cmd.exe fails on a similar way: > > "CS" -o -path "*" no se reconoce como un comando interno o externo, > programa o archivo por lotes ejecutable. Can someone find out what is the command length limit beyond which the command starts to fail? My guess would be that the problem is in cmdproxy, btw. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 14:24 ` Óscar Fuentes 2010-07-20 15:18 ` Juanma Barranquero 2010-07-20 16:56 ` Eli Zaretskii @ 2010-07-20 17:28 ` Eli Zaretskii 2010-07-20 17:42 ` Juanma Barranquero 2010-07-20 19:51 ` Óscar Fuentes 2 siblings, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-07-20 17:28 UTC (permalink / raw) To: Óscar Fuentes; +Cc: lekktu, 6674 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Tue, 20 Jul 2010 16:24:59 +0200 > Cc: 6674@debbugs.gnu.org > > Óscar Fuentes <ofv@wanadoo.es> writes: > > > Agreed. That's a symptom of a more general problem. I have no idea of > > what's going on, because if the pipe is not used the command line for > > `find' is similar on length and the problem doesn't happen. > > Pasting the command on cmd.exe works fine (after replacing / with \ on > the path to `find.exe') > > Executing > > cmd.exe -c <command> > > from cmd.exe fails on a similar way: > > "CS" -o -path "*" no se reconoce como un comando interno o externo, > programa o archivo por lotes ejecutable. > > This looks like a can of worms. Can we apply the patch on the original > post, so `rgrep' is usable on Windows with the minimal fuss? I see the problem. When the command line includes pipes or redirection, cmdproxy calls cmd.exe to do the job. It does so by invoking the `spawn' function. By trial and error I established that the limit beyond which rgrep fails is 1024 characters. This is consistent with the MSDN documentation of _spawn, e.g. http://msdn.microsoft.com/en-us/library/20y988d2(VS.71).aspx which says: To pass arguments to the new process, give one or more pointers to character strings as arguments in the _spawn call. These character strings form the argument list for the spawned process. The combined length of the strings forming the argument list for the new process must not exceed 1024 bytes. [...] Strangely, we use the same _spawn to run commands when there's no pipes or redirection. Perhaps the 1024-character limit is only imposed when cmd.exe is invoked. In general, cmd.exe itself is documented to have a much larger limit on command-line length: 8K on Windows XP. So we could either (1) install Óscar's patch, with the disadvantage that rgrep will be slower on MS-Windows (because a separate Grep is invoked on each file found by Find), or (2) fix cmdproxy to use a better API, such as CreateProcess, which doesn't have this limitation. In any case, please do NOT install the patch for the MS-DOS build. As I wrote earlier, it does not have this problem. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 17:28 ` Eli Zaretskii @ 2010-07-20 17:42 ` Juanma Barranquero 2010-07-20 19:51 ` Óscar Fuentes 1 sibling, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2010-07-20 17:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, 6674 On Tue, Jul 20, 2010 at 19:28, Eli Zaretskii <eliz@gnu.org> wrote: > or (2) fix cmdproxy to use a > better API, such as CreateProcess, which doesn't have this limitation. I think we should do this, unless there's a pressing need to commit a fix ASAP. Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 17:28 ` Eli Zaretskii 2010-07-20 17:42 ` Juanma Barranquero @ 2010-07-20 19:51 ` Óscar Fuentes 2010-07-20 21:41 ` Eli Zaretskii 2010-08-02 10:26 ` Laimonas Vėbra 1 sibling, 2 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-07-20 19:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 6674 Eli Zaretskii <eliz@gnu.org> writes: [snip] > By trial and error I established that the limit beyond which rgrep > fails is 1024 characters. This is consistent with the MSDN > documentation of _spawn, e.g. [snip] > So we could either (1) install Óscar's patch, with the disadvantage > that rgrep will be slower on MS-Windows (because a separate Grep is > invoked on each file found by Find), or (2) fix cmdproxy to use a > better API, such as CreateProcess, which doesn't have this limitation. cmdproxy.c does not call the C runtime `_spawn' function. It defines its own `spawn' that calls CreateProcess. The issue is that "cmd.exe -c" seems to have a 1024 char limit when the command contains a pipe (my guess is that the limit applies separatelly to every command on the pipe chain) and cmdproxy.c prepends "cmd.exe -c" to the command when it has a pipe, redirection, etc. > In any case, please do NOT install the patch for the MS-DOS build. As > I wrote earlier, it does not have this problem. Okay. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 19:51 ` Óscar Fuentes @ 2010-07-20 21:41 ` Eli Zaretskii 2010-07-20 22:18 ` Eli Zaretskii 2010-08-02 10:26 ` Laimonas Vėbra 1 sibling, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2010-07-20 21:41 UTC (permalink / raw) To: Óscar Fuentes; +Cc: lekktu, 6674 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: lekktu@gmail.com, 6674@debbugs.gnu.org > Date: Tue, 20 Jul 2010 21:51:39 +0200 > > The issue is that "cmd.exe -c" seems to have a 1024 char limit when the > command contains a pipe (my guess is that the limit applies separatelly > to every command on the pipe chain) and cmdproxy.c prepends "cmd.exe -c" > to the command when it has a pipe, redirection, etc. If that is true, we could implement the pipes in cmdproxy. It's not difficult. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 21:41 ` Eli Zaretskii @ 2010-07-20 22:18 ` Eli Zaretskii 2010-07-21 0:38 ` Christoph 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2010-07-20 22:18 UTC (permalink / raw) To: ofv, lekktu, 6674 > Date: Wed, 21 Jul 2010 00:41:23 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, 6674@debbugs.gnu.org > > > From: Óscar Fuentes <ofv@wanadoo.es> > > Cc: lekktu@gmail.com, 6674@debbugs.gnu.org > > Date: Tue, 20 Jul 2010 21:51:39 +0200 > > > > The issue is that "cmd.exe -c" seems to have a 1024 char limit when the > > command contains a pipe (my guess is that the limit applies separatelly > > to every command on the pipe chain) and cmdproxy.c prepends "cmd.exe -c" > > to the command when it has a pipe, redirection, etc. > > If that is true, we could implement the pipes in cmdproxy. It's not > difficult. A better (and easier implemented) idea would be to create a temporary batch file with the command line and run the batch file with cmd.exe. The original command works just fine if invoked from a batch file. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 22:18 ` Eli Zaretskii @ 2010-07-21 0:38 ` Christoph 2010-07-21 1:22 ` Óscar Fuentes 0 siblings, 1 reply; 36+ messages in thread From: Christoph @ 2010-07-21 0:38 UTC (permalink / raw) To: bug-gnu-emacs, Eli Zaretskii On 7/20/2010 4:18 PM, Eli Zaretskii wrote: > A better (and easier implemented) idea would be to create a temporary > batch file with the command line and run the batch file with cmd.exe. > The original command works just fine if invoked from a batch file. Out of curiosity, why is a batch file solution better than enhancing cmdproxy? Christoph ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-21 0:38 ` Christoph @ 2010-07-21 1:22 ` Óscar Fuentes 0 siblings, 0 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-07-21 1:22 UTC (permalink / raw) To: bug-gnu-emacs; +Cc: Christoph Christoph <cschol2112@googlemail.com> writes: > On 7/20/2010 4:18 PM, Eli Zaretskii wrote: > >> A better (and easier implemented) idea would be to create a temporary >> batch file with the command line and run the batch file with cmd.exe. >> The original command works just fine if invoked from a batch file. > > Out of curiosity, why is a batch file solution better than enhancing > cmdproxy? Because it is 2 orders of magnitude more simple? Enhancing cmdproxy for correctly parsing | (and `&&', if you are on the mood of doing the full job) then creating the pipes, the processes, deal with error conditions and support Win9X is everything but simple. Two or three more additions of this class, and Microsoft will replace cmd.exe with cmdproxy.exe ;-) ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 19:51 ` Óscar Fuentes 2010-07-20 21:41 ` Eli Zaretskii @ 2010-08-02 10:26 ` Laimonas Vėbra 2010-08-02 15:23 ` Óscar Fuentes 2010-08-02 15:48 ` bug#6674: [PATCH] bug#6674: " Óscar Fuentes 1 sibling, 2 replies; 36+ messages in thread From: Laimonas Vėbra @ 2010-08-02 10:26 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 6674 Óscar Fuentes wrote: > The issue is that "cmd.exe -c" seems to have a 1024 char limit when the > command contains a pipe (my guess is that the limit applies separatelly > to every command on the pipe chain) and cmdproxy.c prepends "cmd.exe -c" > to the command when it has a pipe, redirection, etc. Isn't it wsprintf (used in cmdproxy.c to quote args and for other purposes): http://msdn.microsoft.com/en-us/library/ms647550(VS.85).aspx that imposes 1024 buffer/string length limit...? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 10:26 ` Laimonas Vėbra @ 2010-08-02 15:23 ` Óscar Fuentes 2010-08-02 15:48 ` bug#6674: [PATCH] bug#6674: " Óscar Fuentes 1 sibling, 0 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-08-02 15:23 UTC (permalink / raw) To: Laimonas Vėbra; +Cc: Óscar Fuentes, 6674 Laimonas Vėbra <laimonas.vebra@gmail.com> writes: > Óscar Fuentes wrote: > >> The issue is that "cmd.exe -c" seems to have a 1024 char limit when the >> command contains a pipe (my guess is that the limit applies separatelly >> to every command on the pipe chain) and cmdproxy.c prepends "cmd.exe -c" >> to the command when it has a pipe, redirection, etc. > > Isn't it wsprintf (used in cmdproxy.c to quote args and for other purposes): > http://msdn.microsoft.com/en-us/library/ms647550(VS.85).aspx > > that imposes 1024 buffer/string length limit...? Yes! Patch in progress... ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 10:26 ` Laimonas Vėbra 2010-08-02 15:23 ` Óscar Fuentes @ 2010-08-02 15:48 ` Óscar Fuentes 2010-08-02 17:11 ` Andreas Schwab 2010-08-02 17:48 ` bug#6674: [PATCH fixed] " Óscar Fuentes 1 sibling, 2 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-08-02 15:48 UTC (permalink / raw) To: 6674; +Cc: Christoph, Juanma, Barranquero Laimonas Vėbra <laimonas.vebra@gmail.com> writes: > Isn't it wsprintf (used in cmdproxy.c to quote args and for other purposes): > http://msdn.microsoft.com/en-us/library/ms647550(VS.85).aspx > > that imposes 1024 buffer/string length limit...? 2010-08-02 Óscar Fuentes <ofv@wanadoo.es> * cmdproxy.c (main): use _snprintf instead of wsprintf. Fixes bug#6647. wsprintf has a 1024 char limit on Windows. --- a/nt/cmdproxy.c +++ b/nt/cmdproxy.c @@ -35,6 +35,9 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ #include <stdlib.h> /* getenv */ #include <string.h> /* strlen */ +/* We don't want to include stdio.h because we are alreayd duplicating + lots of it here */ +int _snprintf(char *buffer, size_t count, const char *format, ...); /******* Mock C library routines *********************************/ @@ -604,6 +607,7 @@ main (int argc, char ** argv) { char * p; int extra_arg_space = 0; + int maxlen, remlen; int run_command_dot_com; progname = getenv ("COMSPEC"); @@ -635,21 +639,32 @@ main (int argc, char ** argv) case path contains spaces (fortunately it can't contain quotes, since they are illegal in path names). */ - buf = p = alloca (strlen (progname) + extra_arg_space + - strlen (cmdline) + 16); + remlen = maxlen = + strlen (progname) + extra_arg_space + strlen (cmdline) + 16; + buf = p = alloca (maxlen + 1); /* Quote progname in case it contains spaces. */ - p += wsprintf (p, "\"%s\"", progname); + p += _snprintf (p, remlen, "\"%s\"", progname); + remlen = maxlen - (p - buf); /* Include pass_through_args verbatim; these are just switches so should not need quoting. */ for (argv = pass_through_args; *argv != NULL; ++argv) - p += wsprintf (p, " %s", *argv); + { + p += _snprintf (p, remlen, " %s", *argv); + remlen = maxlen - (p - buf); + } if (run_command_dot_com) - wsprintf(p, " /e:%d /c %s", envsize, cmdline); + { + _snprintf(p, remlen, " /e:%d /c %s", envsize, cmdline); + remlen = maxlen - (p - buf); + } else - wsprintf(p, " /c %s", cmdline); + { + _snprintf(p, remlen, " /c %s", cmdline); + remlen = maxlen - (p - buf); + } cmdline = buf; } else @@ -669,19 +684,27 @@ main (int argc, char ** argv) else path[0] = '\0'; - cmdline = p = alloca (strlen (progname) + extra_arg_space + - strlen (path) + 13); + remlen = maxlen = + strlen (progname) + extra_arg_space + strlen (path) + 13; + cmdline = p = alloca (maxlen + 1); /* Quote progname in case it contains spaces. */ - p += wsprintf (p, "\"%s\" %s", progname, path); + p += _snprintf (p, remlen, "\"%s\" %s", progname, path); + remlen = maxlen - (p - cmdline); /* Include pass_through_args verbatim; these are just switches so should not need quoting. */ for (argv = pass_through_args; *argv != NULL; ++argv) - p += wsprintf (p, " %s", *argv); + { + p += _snprintf (p, remlen, " %s", *argv); + remlen = maxlen - (p - cmdline); + } if (run_command_dot_com) - wsprintf (p, " /e:%d", envsize); + { + _snprintf (p, remlen, " /e:%d", envsize); + remlen = maxlen - (p - cmdline); + } } } ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 15:48 ` bug#6674: [PATCH] bug#6674: " Óscar Fuentes @ 2010-08-02 17:11 ` Andreas Schwab 2010-08-02 17:48 ` bug#6674: [PATCH fixed] " Óscar Fuentes 1 sibling, 0 replies; 36+ messages in thread From: Andreas Schwab @ 2010-08-02 17:11 UTC (permalink / raw) To: Óscar Fuentes; +Cc: Christoph, Juanma, 6674, Barranquero Óscar Fuentes <ofv@wanadoo.es> writes: > +/* We don't want to include stdio.h because we are alreayd duplicating s/yd/dy/ Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 15:48 ` bug#6674: [PATCH] bug#6674: " Óscar Fuentes 2010-08-02 17:11 ` Andreas Schwab @ 2010-08-02 17:48 ` Óscar Fuentes 2010-08-02 19:07 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Óscar Fuentes @ 2010-08-02 17:48 UTC (permalink / raw) To: 6674 Fixed the typo pointed out by Andreas. 2010-08-02 Óscar Fuentes <ofv@wanadoo.es> * cmdproxy.c (main): use _snprintf instead of wsprintf. Fixes bug#6647. wsprintf has a 1024 char limit on Windows. --- a/nt/cmdproxy.c +++ b/nt/cmdproxy.c @@ -35,6 +35,9 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ #include <stdlib.h> /* getenv */ #include <string.h> /* strlen */ +/* We don't want to include stdio.h because we are already duplicating + lots of it here */ +int _snprintf(char *buffer, size_t count, const char *format, ...); /******* Mock C library routines *********************************/ @@ -604,6 +607,7 @@ main (int argc, char ** argv) { char * p; int extra_arg_space = 0; + int maxlen, remlen; int run_command_dot_com; progname = getenv ("COMSPEC"); @@ -635,21 +639,32 @@ main (int argc, char ** argv) case path contains spaces (fortunately it can't contain quotes, since they are illegal in path names). */ - buf = p = alloca (strlen (progname) + extra_arg_space + - strlen (cmdline) + 16); + remlen = maxlen = + strlen (progname) + extra_arg_space + strlen (cmdline) + 16; + buf = p = alloca (maxlen + 1); /* Quote progname in case it contains spaces. */ - p += wsprintf (p, "\"%s\"", progname); + p += _snprintf (p, remlen, "\"%s\"", progname); + remlen = maxlen - (p - buf); /* Include pass_through_args verbatim; these are just switches so should not need quoting. */ for (argv = pass_through_args; *argv != NULL; ++argv) - p += wsprintf (p, " %s", *argv); + { + p += _snprintf (p, remlen, " %s", *argv); + remlen = maxlen - (p - buf); + } if (run_command_dot_com) - wsprintf(p, " /e:%d /c %s", envsize, cmdline); + { + _snprintf(p, remlen, " /e:%d /c %s", envsize, cmdline); + remlen = maxlen - (p - buf); + } else - wsprintf(p, " /c %s", cmdline); + { + _snprintf(p, remlen, " /c %s", cmdline); + remlen = maxlen - (p - buf); + } cmdline = buf; } else @@ -669,19 +684,27 @@ main (int argc, char ** argv) else path[0] = '\0'; - cmdline = p = alloca (strlen (progname) + extra_arg_space + - strlen (path) + 13); + remlen = maxlen = + strlen (progname) + extra_arg_space + strlen (path) + 13; + cmdline = p = alloca (maxlen + 1); /* Quote progname in case it contains spaces. */ - p += wsprintf (p, "\"%s\" %s", progname, path); + p += _snprintf (p, remlen, "\"%s\" %s", progname, path); + remlen = maxlen - (p - cmdline); /* Include pass_through_args verbatim; these are just switches so should not need quoting. */ for (argv = pass_through_args; *argv != NULL; ++argv) - p += wsprintf (p, " %s", *argv); + { + p += _snprintf (p, remlen, " %s", *argv); + remlen = maxlen - (p - cmdline); + } if (run_command_dot_com) - wsprintf (p, " /e:%d", envsize); + { + _snprintf (p, remlen, " /e:%d", envsize); + remlen = maxlen - (p - cmdline); + } } } ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 17:48 ` bug#6674: [PATCH fixed] " Óscar Fuentes @ 2010-08-02 19:07 ` Eli Zaretskii 2010-08-02 19:47 ` Juanma Barranquero 2010-08-02 19:57 ` Óscar Fuentes 0 siblings, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-08-02 19:07 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 6674 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Mon, 02 Aug 2010 19:48:29 +0200 > Cc: > > Fixed the typo pointed out by Andreas. > > 2010-08-02 Óscar Fuentes <ofv@wanadoo.es> > > * cmdproxy.c (main): use _snprintf instead of wsprintf. Fixes > bug#6647. wsprintf has a 1024 char limit on Windows. Thanks. wsprintf supports wide character (UTF-16) strings, whereas _snprintf does not. At the very least, please leave a comment there about that. Better yet, why not use memcpy etc. instead of _snprintf; you don't really need any formatting features anyway. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 19:07 ` Eli Zaretskii @ 2010-08-02 19:47 ` Juanma Barranquero 2010-08-02 19:57 ` Óscar Fuentes 1 sibling, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2010-08-02 19:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, 6674 On Mon, Aug 2, 2010 at 21:07, Eli Zaretskii <eliz@gnu.org> wrote: > wsprintf supports wide character (UTF-16) strings, whereas _snprintf > does not. At the very least, please leave a comment there about that. > Better yet, why not use memcpy etc. instead of _snprintf; you don't > really need any formatting features anyway. I've already committed the change on emacs-23, because it fixes the original report. I'll install any followup patch Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 19:07 ` Eli Zaretskii 2010-08-02 19:47 ` Juanma Barranquero @ 2010-08-02 19:57 ` Óscar Fuentes 2010-08-02 20:11 ` Juanma Barranquero ` (2 more replies) 1 sibling, 3 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-08-02 19:57 UTC (permalink / raw) To: bug-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> Fixed the typo pointed out by Andreas. >> >> 2010-08-02 Óscar Fuentes <ofv@wanadoo.es> >> >> * cmdproxy.c (main): use _snprintf instead of wsprintf. Fixes >> bug#6647. wsprintf has a 1024 char limit on Windows. > > Thanks. > > wsprintf supports wide character (UTF-16) strings, whereas _snprintf > does not. wsprintf supports UTF-16 iff the application is compiled with Unicode support on. cmdproxy uses char, not wchar_t, so if the build switches on Unicode the compilation will fail. > At the very least, please leave a comment there about that. It should be obvious from the type used (char) > Better yet, why not use memcpy etc. instead of _snprintf; you don't > really need any formatting features anyway. It uses "\"%s\"" " %s" " /e:%d /c %s" and more. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 19:57 ` Óscar Fuentes @ 2010-08-02 20:11 ` Juanma Barranquero 2010-08-02 20:15 ` Óscar Fuentes 2010-08-03 2:56 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2010-08-02 20:11 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 6674 2010/8/2 Óscar Fuentes <ofv@wanadoo.es>: > wsprintf supports UTF-16 iff the application is compiled with Unicode > support on. cmdproxy uses char, not wchar_t, so if the build switches on > Unicode the compilation will fail. If there's nothing more to do, please close bug#6674. Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 19:57 ` Óscar Fuentes 2010-08-02 20:11 ` Juanma Barranquero @ 2010-08-02 20:15 ` Óscar Fuentes 2010-08-03 2:56 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-08-02 20:15 UTC (permalink / raw) To: bug-gnu-emacs Óscar Fuentes <ofv@wanadoo.es> writes: >>> * cmdproxy.c (main): use _snprintf instead of wsprintf. Fixes >>> bug#6647. wsprintf has a 1024 char limit on Windows. >> >> Thanks. >> >> wsprintf supports wide character (UTF-16) strings, whereas _snprintf >> does not. > > wsprintf supports UTF-16 iff the application is compiled with Unicode > support on. cmdproxy uses char, not wchar_t, so if the build switches on > Unicode the compilation will fail. This is poorly explained. To begin, cmdproxy, as it was before the patch, does not support UTF-16. For fixing that, you need to start by implementing int wmain(int argc, wchar_t *argv[]) and revise all string handling from there. The workload the patch adds for migrating cmdproxy to UTF-16 would consist on s/_snprintf/_snwprintf. Not doing that would cause compilation errors. [snip] ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: [PATCH fixed] bug#6674: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-08-02 19:57 ` Óscar Fuentes 2010-08-02 20:11 ` Juanma Barranquero 2010-08-02 20:15 ` Óscar Fuentes @ 2010-08-03 2:56 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-08-03 2:56 UTC (permalink / raw) To: Óscar Fuentes; +Cc: bug-gnu-emacs > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Mon, 02 Aug 2010 21:57:16 +0200 > Cc: > > > Better yet, why not use memcpy etc. instead of _snprintf; you don't > > really need any formatting features anyway. > > It uses > > "\"%s\"" > " %s" > " /e:%d /c %s" > > and more. Of which only %d really needs printf-like facility. The rest just copy strings to a buffer. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS 2010-07-20 3:49 bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS Óscar Fuentes 2010-07-20 12:57 ` Juanma Barranquero @ 2010-07-20 16:46 ` Eli Zaretskii 2010-07-20 23:18 ` bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows Óscar Fuentes 2010-08-02 20:17 ` bug#6674: Closing bug 6674 Óscar Fuentes 3 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-07-20 16:46 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 6674 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Tue, 20 Jul 2010 05:49:35 +0200 > Cc: > > On Windows, when find-program points to a GNU-compatible `find' > executable, grep-find-use-xargs is assigned the symbol 'gnu. The > consequence of this is that `rgrep' ends building a command that > contains a pipe: find <args> | xargs -0 grep <args> This ends with > `find' reporting confusing errors about wrong arguments. > > An extra test is added to the assigment of grep-find-use-xargs to force > the value 'exec on Windows and MS-DOS. I saw this problem on MS-Windows and intended to look into it. But one thing is certain: the MS-DOS build does not need this patch, it works just fine with the original command line that includes the pipe to xargs. > + ((or (eq system-type 'windows-nt) (eq system-type 'ms-dos)) What's wrong with memq? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-20 3:49 bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS Óscar Fuentes 2010-07-20 12:57 ` Juanma Barranquero 2010-07-20 16:46 ` bug#6674: PATCH: " Eli Zaretskii @ 2010-07-20 23:18 ` Óscar Fuentes 2010-07-21 0:44 ` Christoph 2010-08-02 20:17 ` bug#6674: Closing bug 6674 Óscar Fuentes 3 siblings, 1 reply; 36+ messages in thread From: Óscar Fuentes @ 2010-07-20 23:18 UTC (permalink / raw) To: 6674; +Cc: lekktu rgrep is broken on Windows. Although it is obvious that a general fix for the shell issue is the most correct resolution for this bug, I propose to apply the patch below and revert it once cmdproxy.c is enhanced for dealing with the problem. Otherwise, a workaround is to add (setq grep-find-use-xargs 'exec) to the user's .emacs file. 2010-07-21 Óscar Fuentes <ofv@wanadoo.es> * progmodes/grep.el (grep-compute-defaults): always assign 'exec to grep-find-use-xargs on Windows. === modified file 'lisp/progmodes/grep.el' *** lisp/progmodes/grep.el 2010-01-31 21:47:47 +0000 --- lisp/progmodes/grep.el 2010-07-20 23:04:56 +0000 *************** Set up `compilation-exit-message-functio *** 552,557 **** --- 552,561 ---- (unless grep-find-use-xargs (setq grep-find-use-xargs (cond + ;; Windows' shell has problems with long commands and + ;; pipes. See bug #6674. + ((eq system-type 'windows-nt) + 'exec) ((and (grep-probe find-program `(nil nil nil ,null-device "-print0")) (grep-probe xargs-program `(nil nil nil "-0" "-e" "echo"))) ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-20 23:18 ` bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows Óscar Fuentes @ 2010-07-21 0:44 ` Christoph 2010-07-21 0:50 ` Juanma Barranquero ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Christoph @ 2010-07-21 0:44 UTC (permalink / raw) To: bug-gnu-emacs; +Cc: Óscar Fuentes, Juanma Barranquero On 7/20/2010 5:18 PM, Óscar Fuentes wrote: > rgrep is broken on Windows. rgrep works fine on Windows with the cygwin port of find (see bug #6665). I did however, run into the issue this patch is describing, too using the GnuWin32 port. > Although it is obvious that a general fix > for the shell issue is the most correct resolution for this bug, I > propose to apply the patch below and revert it once cmdproxy.c is > enhanced for dealing with the problem. If nobody else is already working on it, I'd want to give it a try to fix this. Either by enhancing cmdproxy or implementing Eli's batch file solution. Christoph ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-21 0:44 ` Christoph @ 2010-07-21 0:50 ` Juanma Barranquero 2010-07-21 0:57 ` Óscar Fuentes 2010-07-21 4:02 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2010-07-21 0:50 UTC (permalink / raw) To: Christoph; +Cc: Óscar Fuentes, bug-gnu-emacs On Wed, Jul 21, 2010 at 02:44, Christoph <cschol2112@googlemail.com> wrote: > If nobody else is already working on it, I'd want to give it a try to fix > this. Either by enhancing cmdproxy or implementing Eli's batch file > solution. Thanks! Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-21 0:44 ` Christoph 2010-07-21 0:50 ` Juanma Barranquero @ 2010-07-21 0:57 ` Óscar Fuentes 2010-07-21 4:02 ` Eli Zaretskii 2 siblings, 0 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-07-21 0:57 UTC (permalink / raw) To: Christoph; +Cc: Juanma Barranquero, bug-gnu-emacs Christoph <cschol2112@googlemail.com> writes: > rgrep works fine on Windows with the cygwin port of find (see bug > #6665). I guess you are using cygwin's shell as well, aren't you? Or otherwise the command line for cygwin's `find' is shortened enough to not upset cmd.exe I tried MSYS' find (which is a fork of Cygwin) and it had the same issue. [snip] ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-21 0:44 ` Christoph 2010-07-21 0:50 ` Juanma Barranquero 2010-07-21 0:57 ` Óscar Fuentes @ 2010-07-21 4:02 ` Eli Zaretskii 2010-07-21 4:05 ` Christoph 2010-08-02 2:21 ` Christoph 2 siblings, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-07-21 4:02 UTC (permalink / raw) To: Christoph; +Cc: ofv, lekktu, bug-gnu-emacs > Date: Tue, 20 Jul 2010 18:44:55 -0600 > From: Christoph <cschol2112@googlemail.com> > CC: Eli Zaretskii <eliz@gnu.org>, Juanma Barranquero <lekktu@gmail.com>, > Óscar Fuentes <ofv@wanadoo.es> > > If nobody else is already working on it, I'd want to give it a try to > fix this. Either by enhancing cmdproxy or implementing Eli's batch file > solution. Thanks. To make my intent clear: I meant to enhance cmdproxy to use a batch file when invoking the windows shell. You will see that there's a variable need_shell in cmdproxy's `main' function which gets set to a non-zero value when cmdproxy decides it needs to pass the command the the shell instead of invoking it directly. What I suggested is to modify the code in this case to put the command on a temporary batch file, then invoke the shell on that batch file rather than on the command itself. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-21 4:02 ` Eli Zaretskii @ 2010-07-21 4:05 ` Christoph 2010-08-02 2:21 ` Christoph 1 sibling, 0 replies; 36+ messages in thread From: Christoph @ 2010-07-21 4:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, lekktu, bug-gnu-emacs On 7/20/2010 10:02 PM, Eli Zaretskii wrote: >> Date: Tue, 20 Jul 2010 18:44:55 -0600 >> From: Christoph<cschol2112@googlemail.com> >> CC: Eli Zaretskii<eliz@gnu.org>, Juanma Barranquero<lekktu@gmail.com>, >> Óscar Fuentes<ofv@wanadoo.es> >> >> If nobody else is already working on it, I'd want to give it a try to >> fix this. Either by enhancing cmdproxy or implementing Eli's batch file >> solution. > > Thanks. To make my intent clear: I meant to enhance cmdproxy to use a > batch file when invoking the windows shell. You will see that there's > a variable need_shell in cmdproxy's `main' function which gets set to > a non-zero value when cmdproxy decides it needs to pass the command > the the shell instead of invoking it directly. What I suggested is to > modify the code in this case to put the command on a temporary batch > file, then invoke the shell on that batch file rather than on the > command itself. Thanks for the clarification. I will have a look at that. Christoph ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-07-21 4:02 ` Eli Zaretskii 2010-07-21 4:05 ` Christoph @ 2010-08-02 2:21 ` Christoph 2010-08-02 3:10 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Christoph @ 2010-08-02 2:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, lekktu, bug-gnu-emacs On 7/20/2010 10:02 PM, Eli Zaretskii wrote: > Thanks. To make my intent clear: I meant to enhance cmdproxy to use a > batch file when invoking the windows shell. You will see that there's > a variable need_shell in cmdproxy's `main' function which gets set to > a non-zero value when cmdproxy decides it needs to pass the command > the the shell instead of invoking it directly. What I suggested is to > modify the code in this case to put the command on a temporary batch > file, then invoke the shell on that batch file rather than on the > command itself. Eli, I remember a comment of yours earlier in the thread that DOS does not have the problem. I assume that this is due to a difference in command.com vs cmd.exe? Do we want to execute the batch file only in case of cmd.exe or for both command.com and cmd.exe? Christoph ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-08-02 2:21 ` Christoph @ 2010-08-02 3:10 ` Eli Zaretskii 2010-08-02 4:03 ` Christoph 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2010-08-02 3:10 UTC (permalink / raw) To: Christoph; +Cc: ofv, lekktu, bug-gnu-emacs > Date: Sun, 01 Aug 2010 20:21:43 -0600 > From: Christoph <cschol2112@googlemail.com> > CC: bug-gnu-emacs@gnu.org, lekktu@gmail.com, ofv@wanadoo.es > > On 7/20/2010 10:02 PM, Eli Zaretskii wrote: > > > Thanks. To make my intent clear: I meant to enhance cmdproxy to use a > > batch file when invoking the windows shell. You will see that there's > > a variable need_shell in cmdproxy's `main' function which gets set to > > a non-zero value when cmdproxy decides it needs to pass the command > > the the shell instead of invoking it directly. What I suggested is to > > modify the code in this case to put the command on a temporary batch > > file, then invoke the shell on that batch file rather than on the > > command itself. > > Eli, > I remember a comment of yours earlier in the thread that DOS does not > have the problem. That's right. > I assume that this is due to a difference in command.com vs cmd.exe? No. That's because the DOS port doesn't call command.com at all. It has its own implementation of a shell as part of the `system' function in the standard library it links against. That implementation supports pipes, redirection, quoting, long (up to 16KB) command lines, and a few other minor Posix features, like /dev/null. > Do we want to execute the batch file only in case of cmd.exe or for both > command.com and cmd.exe? Yes, for the benefit of Windows 9X. Thanks. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-08-02 3:10 ` Eli Zaretskii @ 2010-08-02 4:03 ` Christoph 2010-08-02 18:02 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Christoph @ 2010-08-02 4:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnu-emacs On 8/1/2010 9:10 PM, Eli Zaretskii wrote: > No. That's because the DOS port doesn't call command.com at all. It > has its own implementation of a shell as part of the `system' function > in the standard library it links against. That implementation > supports pipes, redirection, quoting, long (up to 16KB) command lines, > and a few other minor Posix features, like /dev/null. I see. Just out of curiosity, why can't this shell implementation be used for Windows? >> Do we want to execute the batch file only in case of cmd.exe or for both >> command.com and cmd.exe? > > Yes, for the benefit of Windows 9X. Sounds good. Thanks. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows 2010-08-02 4:03 ` Christoph @ 2010-08-02 18:02 ` Eli Zaretskii 0 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2010-08-02 18:02 UTC (permalink / raw) To: Christoph; +Cc: bug-gnu-emacs > Date: Sun, 01 Aug 2010 22:03:29 -0600 > From: Christoph <cschol2112@googlemail.com> > CC: bug-gnu-emacs@gnu.org > > On 8/1/2010 9:10 PM, Eli Zaretskii wrote: > > > No. That's because the DOS port doesn't call command.com at all. It > > has its own implementation of a shell as part of the `system' function > > in the standard library it links against. That implementation > > supports pipes, redirection, quoting, long (up to 16KB) command lines, > > and a few other minor Posix features, like /dev/null. > > I see. Just out of curiosity, why can't this shell implementation be > used for Windows? (Looks like the original bug is fixed already, but I will answer this anyway, for the record.) Yes, we could do that. The source of the DJGPP implementation used by the DOS port is Free Software. However, this is a non-trivial job, because porting that code to Windows will need some reimplementation. E.g., pipes are implemented with temporary files and commands are run sequentially, one by one (this is DOS, right?), but on Windows we have real pipes and we should run both sides of the pipe concurrently. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#6674: Closing bug 6674 2010-07-20 3:49 bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS Óscar Fuentes ` (2 preceding siblings ...) 2010-07-20 23:18 ` bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows Óscar Fuentes @ 2010-08-02 20:17 ` Óscar Fuentes 3 siblings, 0 replies; 36+ messages in thread From: Óscar Fuentes @ 2010-08-02 20:17 UTC (permalink / raw) To: 6674-done Patch committed. ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2010-08-03 2:56 UTC | newest] Thread overview: 36+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-20 3:49 bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS Óscar Fuentes 2010-07-20 12:57 ` Juanma Barranquero 2010-07-20 13:39 ` Óscar Fuentes 2010-07-20 14:24 ` Óscar Fuentes 2010-07-20 15:18 ` Juanma Barranquero 2010-07-20 16:56 ` Eli Zaretskii 2010-07-20 17:28 ` Eli Zaretskii 2010-07-20 17:42 ` Juanma Barranquero 2010-07-20 19:51 ` Óscar Fuentes 2010-07-20 21:41 ` Eli Zaretskii 2010-07-20 22:18 ` Eli Zaretskii 2010-07-21 0:38 ` Christoph 2010-07-21 1:22 ` Óscar Fuentes 2010-08-02 10:26 ` Laimonas Vėbra 2010-08-02 15:23 ` Óscar Fuentes 2010-08-02 15:48 ` bug#6674: [PATCH] bug#6674: " Óscar Fuentes 2010-08-02 17:11 ` Andreas Schwab 2010-08-02 17:48 ` bug#6674: [PATCH fixed] " Óscar Fuentes 2010-08-02 19:07 ` Eli Zaretskii 2010-08-02 19:47 ` Juanma Barranquero 2010-08-02 19:57 ` Óscar Fuentes 2010-08-02 20:11 ` Juanma Barranquero 2010-08-02 20:15 ` Óscar Fuentes 2010-08-03 2:56 ` Eli Zaretskii 2010-07-20 16:46 ` bug#6674: PATCH: " Eli Zaretskii 2010-07-20 23:18 ` bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows Óscar Fuentes 2010-07-21 0:44 ` Christoph 2010-07-21 0:50 ` Juanma Barranquero 2010-07-21 0:57 ` Óscar Fuentes 2010-07-21 4:02 ` Eli Zaretskii 2010-07-21 4:05 ` Christoph 2010-08-02 2:21 ` Christoph 2010-08-02 3:10 ` Eli Zaretskii 2010-08-02 4:03 ` Christoph 2010-08-02 18:02 ` Eli Zaretskii 2010-08-02 20:17 ` bug#6674: Closing bug 6674 Óscar Fuentes
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).