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: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: 6784 <at> debbugs.gnu.org
Subject: 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.

Previous Next

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