• Please review our updated Terms and Rules here

How to successfully redirect command.com's default location...

I've seen that before - try using the PATH statement in a small autoexec on your bootable floppy for all applicable drives, i.e. PATH=A:\;B:\;C:\ . . . etc. (including a RAM drive if any). Also try SET COMMAND.COM=A:\ may help it it's overwritten by some means in high memory.
 
Agent Orange said:
I've seen that before - try using the PATH statement in a small autoexec on your bootable floppy for all applicable drives, i.e. PATH=A:\;B:\;C:\ . . . etc. (including a RAM drive if any). Also try SET COMMAND.COM=A:\ may help it it's overwritten by some means in high memory.
Click to expand...
The PATH statement does not govern where command.com looks for it's transient part to reload it. It is just the search path for command line executables.
 
Ole Juul said:
Then I guess I'm not understanding something - sorry. I'm seeing this an anomaly in how DOS is reading the shell= command or subsequent comspec= variable. IOW, not doing what it's told. :)
Click to expand...
And I'm not following your line of reasoning since I still think it is doing what it is told. :)
 
Try this. Set your test up as normal, but instead of using the floppy drive as your default drive, try setting your default (logged in ) drive as the RAM drive. I can see where COMSPEC may silently skip setting the drive where your COMMAND.COM is located and use the default drive instead. COMSPEC isn't handled in a single place--there are places in both COMMAND1 and COMMAND2 where it's looked at.
 
Sorry, but you lost me on that one, Chuck. :) If you mean run something on the ramdrive that will require DOS to reload the transient part of command.com... that doesn't work if I pull command.com from the floppy it booted from initially, even when command.com is on the ramdrive. If you mean something else... gimme some more details. :)
 
Okay, put COMMAND.COM on your RAMdrive, set COMSPEC in your AUTOEXEC to point to it.

Let's suppose for the sake of argument that your RAMDrive is R:, and that the program that you want to run from the A: drive is WHAT.EXE. Normally, you'd be at an A: prompt and you'd enter WHAT on the command line.

Instead, log into R:, so that you have an R:> prompt and then run your program from the A: drive as A:WHAT on the command line.

I'm staring at some code in COMMAND.COM that I don't quite understand; I wonder if there's a bug in the drive decipherment in COMMAND. It does special case COMSPEC.
 
I feel ignored ;-(

Did you try any of my suggested solutions?

AFAIK the c:\ parameter after command.com should do exactly what you want, but I don't know if command.com actually has to be on the RAM drive when SHELL is processed; I don't believe so but I'm not in a position to try it right now.

Edit: apparently it doesn't, but it still doesn't seem to work the way I thought.

In any case, a secondary Command.com on the RAMdisk should work.
 
Last edited:
Stone said:
And I'm not following your line of reasoning since I still think it is doing what it is told. :)
Click to expand...

I am reasoning that if it followed the comspec command "when told", then you would not have a problem. :)

Anyway, I didn't see what you "told" it. Did you use the /p switch? I think you need to do that.

Code: 
/P
    Should be used only when COMMAND is used with the SHELL command in the
    CONFIG.SYS file. The /P switch makes the new copy of the command
    interpreter permanent. In this case, the EXIT command cannot be used to
    stop the command interpreter. If you specify /P, MS-DOS runs your
    AUTOEXEC.BAT file before displaying the command prompt. If there is no
    AUTOEXEC.BAT file in the root directory of the startup drive, MS-DOS
    carries out the DATE and TIME commands instead. If you do not have a
    SHELL command in your CONFIG.SYS file, COMMAND.COM is automatically
    loaded from the root directory with the /P switch.
 
Ole Juul said:
I am reasoning that if it followed the comspec command "when told", then you would not have a problem. :)

Anyway, I didn't see what you "told" it. Did you use the /p switch? I think you need to do that.
Click to expand...

AFAIK if you invoke COMMAND.COM with SHELL = then the /p switch will make that the primary command processor and carry on as usual processing autoexec.bat etc.; without the /p switch you will invoke a secondary COMMAND.COM

Now, if that secondary COMMAND.COM has the /p option set then you will not be able to return to the primary; without /p an EXIT will take you out and back.
 
I just tried setting COMSPEC and I have to agree with Ole; it seems to work just the way it's supposed to and do what Stone wants to do, so I wonder what's different?

Edit: Sorry, I'd missed Chuck's last reply; yes, that should work, but it shouldn't even be necessary to log on to 'R'.

Seems like a lot of confusion over something fairly straightforward...
 
Last edited:
MikeS said:
AFAIK if you invoke COMMAND.COM with SHELL = then the /p switch will make that the primary command processor and carry on as usual processing autoexec.bat etc.; without the /p switch you will invoke a secondary COMMAND.COM

Now, if that secondary COMMAND.COM has the /p option set then you will not be able to return to the primary; without /p an EXIT will take you out and back.
Click to expand...

It's been many years since I've had a command.com in my root directory, and there seems to be no practical reason for putting it there. As for the shell command, I'm no expert, but I know what works. As mentioned before, this works:

Code: 
shell=c:\sys\ms\command.com c:\sys\ms /e:1024 /p /f

It does not work without the /p - I just tried that. :)
 
Ole Juul said:
...As for the shell command, I'm no expert, but I know what works. As mentioned before, this works:

Code: 
shell=c:\sys\ms\command.com c:\sys\ms /e:1024 /p /f

It does not work without the /p - I just tried that. :)
Click to expand...
Odd; seems to work fine for me, although as I said it does start a secondary command.com.

What happens when you leave out the /p ?
 
The /p says that it's the permanent one; i.e. it keeps a resident. Non-/p ones store permanent shell data in the permanent shell's resident data area.

I agree that COMSPEC should work, but then I don't have Stone's system--and there have been a potload of fixes to COMMAND.COM
 
MikeS said:
What happens when you leave out the /p ?
Click to expand...
I end up at a C:\ prompt with no autoexec.bat having been run. I had to type in a path so I could edit the config.sys and boot properly again. lol Anyway, that's probably a side effect of some of the odd things I do like make my config.sys and autoexec.bat hidden and read only - they being edited and backed up with a bat command. I don't know if it had anything to do with not having a command.com in the root. I'll check that.
 
Ole Juul said:
I end up at a C:\ prompt with no autoexec.bat having been run.
Click to expand...
Ah, no, since it's not really the primary shell it doesn't run AUTOEXEC (just as if you ran command.com from a prompt or specifiied /d); you'd have to run it manually, but otherwise everything should be fine (until you type 'EXIT' ;-) Fortunately that seems to default OK).

Anyway, the bottom line (as I suggested back in post #6 ;-) ) seems to be that starting a secondary shell on the RAM disk will solve Stone's problem, whether he uses COMSPEC or just runs COMMAND.COM ( I think COMSPEC uses a little less memory).

Forget my second proposed solution; I was confusing the /p (permanent/non-permanent) shell option with the resident/transient parts of command/com (not to mention splitting it into high and low memory parts ;-) ).

The third option suffers from the chicken/egg problem; You can specify the RAM disk as the location of the transient part (the C:\ option for COMMAND.COM) even though it's not there at SHELL time, but when COMMAND.COM starts it decides that that location is invalid and subsequently fails if/when it has to reload the transient part.
 
Last edited:
MikeS said:
Ah, no, since it's not really the primary processor it doesn't run AUTOEXEC (just as if you ran command.com from a prompt); you'd have to run it manually, but otherwise everything should be fine (until you type 'EXIT' ;-) Fortunately that seems to default OK).
Click to expand...

I'm not sure I understand your comment. Anyway, typing "EXIT" results in "no command interpreter" and gives no response if done when the /p switch is used.

Removing the /p results in no AUTOEXEC.BAT being run here, although I see now that I can run it by hand. I just tried a number of times with variations such as giving config files normal attributes and putting COMMAND.COM in the root directory. In all cases there is no BAT being run without the /p switch. Put the /p back and all is good. This is MS-DOS 6.22.
 
Ole Juul said:
I'm not sure I understand your comment. Anyway, typing "EXIT" results in "no command interpreter" and gives no response if done when the /p switch is used.

Removing the /p results in no AUTOEXEC.BAT being run here, although I see now that I can run it by hand. I just tried a number of times with variations such as giving config files normal attributes and putting COMMAND.COM in the root directory. In all cases there is no BAT being run without the /p switch. Put the /p back and all is good. This is MS-DOS 6.22.
Click to expand...
Yes, like I said not specifying COMMAND.COM's /p option when using SHELL makes the primary COMMAND.COM non-permanent, just like typing COMMAND.COM at a prompt which does not run autoexec.bat either. The difference is that typing COMMAND.COM creates a second level shell and EXIT will take you back up one level to the shell above it; if you EXIT from the primary shell there is no shell above it to EXIT to.

Bottom line: unless you have a good reason not to, always specify the /p COMMAND.COM option if invoking it with SHELL; if you're invoking COMMAND.COM from a prompt then you should leave it off if you want to be able to return to the previous shell environment.
 
Last edited:
Ole Juul said:
I am reasoning that if it followed the comspec command "when told", then you would not have a problem. :)

Anyway, I didn't see what you "told" it. Did you use the /p switch? I think you need to do that.
Click to expand...
OK, everything works as hoped/expected regarding the use of the SHELL command to get the redirection to a drive of choice (other than the ramdrive). The only sticking point is that I'd prefer to have the ramdrive serve as the host of the copy of command.com for transient reloading purposes. So far I haven't been able to do that.
 
You must log in or register to reply here.
Back
Top