make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch for missing shell commands in rc2


From: J. David Bryan
Subject: Re: Patch for missing shell commands in rc2
Date: Tue, 21 Mar 2006 17:35:45 -0500

On 21 Mar 2006 at 22:21, Eli Zaretskii wrote:

> ...the way commands are invoked via the shell is very different from
> how programs are invoked directly.... 

I understand (correctly, I hope) that CreateProcess is passed a temporary 
batch filename for shell commands and the name of the executable for direct 
invocation.


> One notable problem is the forward vs backslashes in file names: when
> you invoke "c:/foo/bar/baz.exe" from the shell, you must first convert
> the forward slashes to backslashes.

Granted.  But the added shell commands wouldn't contain slashes in their 
invocations, so I don't understand your example.

I'm trying to think of a case where that would be a problem as a result of 
adding new commands to the sh_cmds_dos set.  Are you thinking that someone 
using command.com might have a makefile that invokes a command with the 
same name as a cmd.exe internal command, is currently passing forward-
slashed filenames to it, which it accepts, whereas if the same parameters 
were passed via a batch file invocation, it wouldn't?


> Another problem is the 126-character limit on COMMAND.COM's command
> line; invoking programs directly via CreateProcess won't hit this
> limit. 

You're worried here too about a pre-existing 9x makefile that uses a 
command with the same name as an NT-shell command and that has a command 
line containing more than 126 characters?


> In short, this would be an incompatible change, which I don't think
> we should do now, 5 minutes before the release of v3.81.

I concede the 126-character limitation might produce an incompatibility, if 
someone is currently invoking a command whose name conflicts with a cmd.exe 
internal command, and if the command line in use is > 126 characters.  I'm 
not sure that the forward-slash example you gave applies, though.


> OTOH, it should be very easy to do this at run time rather than at
> compile time, if $SHELL is cmd.exe.  Why risk problematic changes when
> the Right Thing is so easily done?

Hmmm...how easily done is it?  Would you set sh_cmds differently for 
command.com and cmd.exe each time through construct_command_argv_internal?  
Would you obtain and parse COMSPEC each time through?  $SHELL on my systems 
appears to default to sh.exe (it's not set otherwise in the environment or 
makefile).  Parse and save COMSPEC once on startup and SHELL each time 
through?

I'll give it a try, with some guidance here.  As it is now, I can't use a 
makefile containing the command "start <something>" on NT and 9x without 
hand waving.

                                      -- Dave





reply via email to

[Prev in Thread] Current Thread [Next in Thread]