Re: wcmd: strip quotes around executable and retry on error

[Thomas Kho]

On 7/6/06, Thomas Kho  wrote:
> wcmd: strip quotes around executable and retry on error
> wcmd currently gives a 'File not found' error for the command:
> `./wine wcmd /c "notepad test.txt"` because it only tries to execute the
> program "notepad text.txt". In XP, cmd.exe starts notepad.exe with test.txt as
> its argument upon not finding a "notepad text.txt" executable.

Hi,

Is there something wrong with this patch?
http://www.winehq.org/pipermail/wine-patches/2006-July/028367.html

Thanks,

Thomas Kho

wcmd: strip quotes around executable and retry on error

[Robert Shearman]

Thomas Kho wrote:
> On 7/6/06, Thomas Kho  wrote:
> > wcmd: strip quotes around executable and retry on error
> > wcmd currently gives a 'File not found' error for the command:
> > `./wine wcmd /c "notepad test.txt"` because it only tries to execute the
> > program "notepad text.txt". In XP, cmd.exe starts notepad.exe with 
> > test.txt as
> > its argument upon not finding a "notepad text.txt" executable.
>
> Hi,
>
> Is there something wrong with this patch?
> http://www.winehq.org/pipermail/wine-patches/2006-July/028367.html

It could probably be fixed by creating a fake notepad.exe in C:\Windows 
or C:\Windows\system32 instead of duplicating some of the work of 
CreateProcess.

wcmd: strip quotes around executable and retry on error

[Thomas Kho]

On 7/11/06, Robert Shearman  wrote:
> Thomas Kho wrote:
> > On 7/6/06, Thomas Kho  wrote:
> > > wcmd: strip quotes around executable and retry on error
> > > wcmd currently gives a 'File not found' error for the command:
> > > `./wine wcmd /c "notepad test.txt"` because it only tries to execute the
> > > program "notepad text.txt". In XP, cmd.exe starts notepad.exe with
> > > test.txt as
> > > its argument upon not finding a "notepad text.txt" executable.
> >
> > Hi,
> >
> > Is there something wrong with this patch?
> > http://www.winehq.org/pipermail/wine-patches/2006-July/028367.html
>
> It could probably be fixed by creating a fake notepad.exe in C:\Windows
> or C:\Windows\system32 instead of duplicating some of the work of
> CreateProcess.

A fake notepad.exe is currently created in c:\windows\system32. I
don't think there's duplication of CreateProcess because CreateProcess
considers the filename of the executable to be the first quoted term
in the commandline. In contrast, cmd.exe also considers the first
space-separated word of that quoted string as the filename of the
executable when the entire quoted term is not an executable.

Thomas Kho

wcmd: strip quotes around executable and retry on error

[Francois Gouget]

On Tue, 11 Jul 2006, Thomas Kho wrote:
[...]
> A fake notepad.exe is currently created in c:\windows\system32. I
> don't think there's duplication of CreateProcess because CreateProcess
> considers the filename of the executable to be the first quoted term
> in the commandline. In contrast, cmd.exe also considers the first
> space-separated word of that quoted string as the filename of the
> executable when the entire quoted term is not an executable.

CreateProcess does that too:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas...

wcmd: strip quotes around executable and retry on error

[Thomas Kho]

On 7/21/06, Francois Gouget  wrote:
> On Tue, 11 Jul 2006, Thomas Kho wrote:
> [...]
> > A fake notepad.exe is currently created in c:\windows\system32. I
> > don't think there's duplication of CreateProcess because CreateProcess
> > considers the filename of the executable to be the first quoted term
> > in the commandline. In contrast, cmd.exe also considers the first
> > space-separated word of that quoted string as the filename of the
> > executable when the entire quoted term is not an executable.
>
> CreateProcess does that too:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas...

It doesn't follow the ambiguous file name searching for CreateProcess.
I just re-read the cmd.exe help output and realized that it spells out
the logic for quotes when /c is specified. My patch was overarching in
also affecting commands entered at the command prompt; it should only
affect the command line passed in as an argument with the /c flag.

Tommy