[Top][All Lists]
[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: |
Wed, 22 Mar 2006 13:05:03 -0500 |
On 22 Mar 2006 at 6:40, Eli Zaretskii wrote:
> My example is with the following command:
>
> start c:/foo/bar/baz.exe
>
> Do you see the issue now?
I'm afraid not, because the above works fine in Win95 and Win98, e.g. Try:
start c:/windows/notepad.exe
...under command.com, and I believe that you'll see that notepad starts as
expected.
I recognize that trying to do "c:/windows/notepad.exe" directly from the
shell doesn't work and that "c:\windows\notepad.exe" is required instead,
but the problem there doesn't pertain to internal commands, which are
started without paths (we don't do "c:/windows/start" if "start" is an
internal command).
> > 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?
>
> Yes, see above.
After considering my example more, I'm not sure that pertains either.
Command.com doesn't appear to alter the parameters passed to an external
command, so if that command accepted forward-slashed parameters before, it
should still work with forward-slashed parameters even if it's started via
the shell. Command.com seems to object only when forward slashes in
filenames are passed to internal commands, where the slashes are confused
with command switches.
Also, you had written earlier:
> Another problem is the 126-character limit on COMMAND.COM's command
> line; invoking programs directly via CreateProcess won't hit this
> limit.
MSDN says that the limit for batch command lines, i.e., how make runs shell
commands, is 1024 characters under command.com:
http://msdn.microsoft.com/archive/en-us/win9x/msdos_694j.asp
So I believe that the only incompatibility my original patch would cause
would be to existing makefiles running under command.com that had issued
command lines longer than 1024 characters to programs whose names conflict
with the added cmd.exe shell command names. Counterexamples welcomed,
though.
If you believe that limitation is too restrictive, however, I'm willing to
undertake the selection of sh_cmds_dos at run time. That would appear to
add some overhead to every command execution, though.
> Feel free to ask for advice.
Your offer is appreciated.
> I cannot imagine you really need to invoke a command via "start" in a
> Makefile. If that's a real example, can you describe it in mode
> detail?
I have three situations that use "start" in the makefile as a convenience:
* image processing -- the makefile runs a series of programs on image
files and then starts a viewer or editor on the result
* pdf generation -- the makefile compiles a pdf from a series of image
files and then starts Acrobat Reader to view the result
* program debugging -- the makefile compiles a program and then starts gdb
on the executable.
In all cases, I can run the last step manually, e.g., run the image editor,
do File | Open, navigate to the processed file, and load it. Much nicer to
have the makefile do that automatically, though.
-- Dave
- Patch for missing shell commands in rc2, J. David Bryan, 2006/03/20
- Re: Patch for missing shell commands in rc2, Eli Zaretskii, 2006/03/20
- Re: Patch for missing shell commands in rc2, J. David Bryan, 2006/03/21
- Re: Patch for missing shell commands in rc2, Eli Zaretskii, 2006/03/21
- Re: Patch for missing shell commands in rc2, J. David Bryan, 2006/03/27
- Re: Patch for missing shell commands in rc2, Eli Zaretskii, 2006/03/21
- Re: Patch for missing shell commands in rc2,
J. David Bryan <=
- Re: Patch for missing shell commands in rc2, Eli Zaretskii, 2006/03/22
- Re: Patch for missing shell commands in rc2, J. David Bryan, 2006/03/22
Re: Patch for missing shell commands in rc2, Paul D. Smith, 2006/03/20