gapp@pur-ee.UUCP (GAPP Research) (09/22/89)
Cheers,
I tested a program that I received recently, and found this
searching failure problem when I tried to execute some of its
included options. I then was kicked out from the program.
The program creates it an independent directory c:\X. All its
modules stays under it. It also creates a subdirectory c:\X\Y
as its working environment. To run the program, a shell (.BAT)
command switches the current directory to that working directory
Y. When I run this program via a number of options it supported,
it says,
Specified COMMAND search directry bad
Specified COMMAND search directry bad
Specified COMMAND search directry bad
Specified COMMAND search directry bad
Specified COMMAND search directry bad
Command v. 3.10 (C) Copyright Microsoft Corp 181, 1985
C>
When I checked this with
c>set
it shows
PATH=
COMSPEC=/COMMAND.COM
Then I have to do "exit" to let me go back to DOS, lost
all the efforts I have done with the program.
Is there anything I did wrong with the system? The COMSPEC is
specified in config.sys. What caused this funny problem?
Any help is appreciated. Please email to the address below. I am
using a lab account to post this.
--aynang
Internet: aynang@ed.ecn.purdue.edu
UUCP: pur-ee!ed!aynangNU013809@NDSUVM1.BITNET (Greg Wettstein) (10/05/89)
I experienced a similar problem just recently when I was porting GNU Make to
MS-DOS. The symptoms were very similar to what the previous poster noticed,
make would attempt to spawn a copy of command.com to run a command. I was
using the spawnve command to execute command.com with the /c switch which tells
command.com to execute its arguement and return to DOS. The format of the
spawnve function call is MSC 5.1 is: spawnve(mode, program, argv, envp)
Where: mode = Mode to use when spawning, P_WAIT is the only option
available in MS-DOS.
program = Ghe name of the program to be spawned.
argv = An array of character pointerw which point to the command
line arguements.
envp = An array of character pointers which point to the
environment strings to be used by the child process.
The format of the argv strings were as follows:
argv[0] = "c::command.com" <---- The name of the program to execute.
argv[1] = "-c" <---- The execute and return switch.
argv[2] = "dir" <---- Command to execute.
argv[3] = "" <---- Null to terminate arguement list.
When command.com was spawned with this arguement list an error was issued
repeatedly which said that an invalid search path was found. Control then
returned to the daughter copy of command.com. Typing an exit command would
return control back to MAKE. Checking the environment revealed that the only
environment strings present were: PATH= and COMSPEC=:command.com.
I scratched my head a couple of times, checked that the arguements were all
correct before the spawnve call and then started to look for problems. Those
readers who have been observant have already spotted the problem. I used a
-c instead of a /c as an arguement string. Evidently command.com could not
cope with this and exits leaving an essentially empty operating shell.
I don't know for certain if this is happening with the poster's program but the
symptoms are notoriously similar. Obvious solutions are to:
1:=> Check the source code if it is available for a spawn or exec command.
2:=> If source is not available check to see if the user can provide any
type of configuration for how commands are to be spawned, arguements
etc.
3:=> Use one of the programs floating around the net that uses the
undocumented DOS function to change the current switch character
setting. I have heard conflicting reports on whether or not
command.com checks the current switch character setting before
parsing command lines passed to it.
Hopefully this information will cast some light on the problem. I apologize
if people should find this excessively verbose. This problem cost me some
time and I would like others to avoid it if possible.
As always,
Dr. G.W. Wettstein
NU013809@NDSUVM1mju@mudos.ann-arbor.mi.us (Marc Unangst) (10/06/89)
In article <2882NU013809@NDSUVM1>, NU013809@NDSUVM1.BITNET (Greg Wettstein) writes: > argv[0] = "c::command.com" <---- The name of the program to execute. > > argv[1] = "-c" <---- The execute and return switch. > > argv[2] = "dir" <---- Command to execute. > > argv[3] = "" <---- Null to terminate arguement list. > > >When command.com was spawned with this arguement list an error was issued >repeatedly which said that an invalid search path was found. Control then >returned to the daughter copy of command.com. Typing an exit command would >return control back to MAKE. Checking the environment revealed that the only >environment strings present were: PATH= and COMSPEC=:command.com. Well, I can see several problems... 1. COMSPEC should be a fully-qualified pathname. ":command.com" isn't even a legal one, so I'm very surprised that your machine hasn't crashed with a "Can't load COMMAND.COM/System Halted." message yet. You must be lucky. The correct COMSPEC would be "c:\command.com". 2. COMMAND.COM wants to have "/" in some versions of DOS; in others, it likes the current switch character. Use getswitchar() (if you use Turbo C; if you're using MSC, you'll have to muck about with inline assembly) to grab the current switch character, and use that. UNDER NO CONDITIONS should you hardcode "-c" in. (Note: It might just be easier to have a runtime environment variable or config-file option that specifies how to execute a command.) 3. You should not hardcode in COMMAND.COM. I'm sure there are a lot of MKS people out there who swear up a storm every time a program that has COMMAND.COM locked in comes down the pipe. Please use COMSPEC or a user-defined variable. > setting. I have heard conflicting reports on whether or not > command.com checks the current switch character setting before > parsing command lines passed to it. That's because different versions of DOS work differently. There are some versions that have "/" coded in, others use switchar, and others are just plain weird. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832 ?