[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS
From: |
Eli Zaretskii |
Subject: |
bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS |
Date: |
Tue, 20 Jul 2010 20:28:04 +0300 |
> 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.
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Óscar Fuentes, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Juanma Barranquero, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Óscar Fuentes, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Óscar Fuentes, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Juanma Barranquero, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Eli Zaretskii, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS,
Eli Zaretskii <=
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Juanma Barranquero, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Óscar Fuentes, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Eli Zaretskii, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Eli Zaretskii, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Christoph, 2010/07/20
- bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Óscar Fuentes, 2010/07/20
bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows/MS-DOS, Eli Zaretskii, 2010/07/20
bug#6674: PATCH: fix assignment of grep-find-use-xargs on Windows, Óscar Fuentes, 2010/07/20