02-16-2004, 12:49 AM
02-16-2004, 06:05 AM
Here's the exact batchfile referred to:
The TYPE and ECHO commands are just to see if the batchfile executed ok. They do.
The PATH that exists when you get into the DOS Shell is quite long.
THEBIGBASICO: I sincerely have tried to explain this as best as possible. What do you mean by "Which app am I using"?
ANTONI: I doubt if the utility program, which does the DOS Shell, can exercise any control as to what gets executed. Besides, forget the utility for a minute, the same thing happens when I run the old interpreted BASIC and type in a direct command of SHELL.
*****
Code:
path=c:\
type tt13.bas
echo qwertThe PATH that exists when you get into the DOS Shell is quite long.
THEBIGBASICO: I sincerely have tried to explain this as best as possible. What do you mean by "Which app am I using"?
ANTONI: I doubt if the utility program, which does the DOS Shell, can exercise any control as to what gets executed. Besides, forget the utility for a minute, the same thing happens when I run the old interpreted BASIC and type in a direct command of SHELL.
*****
02-16-2004, 06:32 AM
Well, that disproves my theory, so I don't have a clue on what's happening.
But I've thought about a walkaround: make a batch file which sets the PATH and then call your application. Run that BAT file instead of the application and you'll be guaranteed to have a working PATH environment variable when you open a MSDOS shell from within your application:
But I've thought about a walkaround: make a batch file which sets the PATH and then call your application. Run that BAT file instead of the application and you'll be guaranteed to have a working PATH environment variable when you open a MSDOS shell from within your application:
Code:
set path=c:\whatever;c:\anotherthing;c:\bleh
myprog.exe02-16-2004, 07:47 AM
Nathan,
I don't know what you mean by "my application".
*****
I don't know what you mean by "my application".
*****
02-16-2004, 09:03 AM
The program you are shelling from:
Quote:I get into this shell from a utility program which has an option "go to DOS".
02-16-2004, 04:02 PM
Moneo:
You have said the magic word: "it is rather long"
DOS has a size limit for path, if you try to go beyond it, PATH commands are not accepted.
You should try to keep your base path to a minimum, adding other paths only the time to execute a program..
About the program filtering shell commands, it is one thing old AutoCad 10 for DOS was able to do. I suppose they loaded their own Command.com.. After all, modifying paths while running a program could be dangerous for the program.
You have said the magic word: "it is rather long"
DOS has a size limit for path, if you try to go beyond it, PATH commands are not accepted.
You should try to keep your base path to a minimum, adding other paths only the time to execute a program..
About the program filtering shell commands, it is one thing old AutoCad 10 for DOS was able to do. I suppose they loaded their own Command.com.. After all, modifying paths while running a program could be dangerous for the program.
02-17-2004, 03:02 AM
Antoni,
The original path was long, but the path that I'm trying to change to from the batchfile is short (C:\).
*****
The original path was long, but the path that I'm trying to change to from the batchfile is short (C:\).
*****
02-17-2004, 04:50 AM
I dont know if i understand it at all. I try to explain what i suppouse is happen as best as i can.
Suppouse you have program A, a BAT file B.
Now you start from command.com (this will be the parent shell P), you call A, and then make a DOS-Shell (this is another instance of command.com and is Q), and execute B file.
Any changes that make B to the environment will be lost.
P is the grandfather, A is the father, and Q is the child. B modify the Q environment, and this changes will be lost when you type EXIT and return to A.
If you want that A modify P environment, you have to examine A PSP a find where is P PSP (who is A parent), and then examine P PSP to find the environment.
I hope to be as clear as possible.
Suppouse you have program A, a BAT file B.
Now you start from command.com (this will be the parent shell P), you call A, and then make a DOS-Shell (this is another instance of command.com and is Q), and execute B file.
Any changes that make B to the environment will be lost.
P is the grandfather, A is the father, and Q is the child. B modify the Q environment, and this changes will be lost when you type EXIT and return to A.
If you want that A modify P environment, you have to examine A PSP a find where is P PSP (who is A parent), and then examine P PSP to find the environment.
I hope to be as clear as possible.
02-17-2004, 05:58 AM
No, that is not what's happening.
He opens his application, goes to a dos Shell, calls a BAT file containing a PATH statement, and then (before exiting the dos shell) he checks if the PATH has changed and it hasn't.
That's the problem. And that happens to me as well, I've tried it.
What I suggested is that he created a BATch file which set the PATH and then launched the application. That way, when he opened the dos Shell from within the application, the PATH would have the correct value. This is a walk-around, and it has worked for me. I don't know if that worked for him, I didn't get any reply.
He opens his application, goes to a dos Shell, calls a BAT file containing a PATH statement, and then (before exiting the dos shell) he checks if the PATH has changed and it hasn't.
That's the problem. And that happens to me as well, I've tried it.
What I suggested is that he created a BATch file which set the PATH and then launched the application. That way, when he opened the dos Shell from within the application, the PATH would have the correct value. This is a walk-around, and it has worked for me. I don't know if that worked for him, I didn't get any reply.
02-17-2004, 08:14 AM
Nathan,
Ok, I tried your theory.
1) I created a batchfile which set the path to C:\MONEO.
2) I executed above batchfile from Windows by going to "My Computer", selecting the above batch file, and double click to run it. The screen went black for a second so it must have run it.
3) Again from "My Computer", I select what you call "my application" which is really an old version of the LIST utility. I double click to run it, pick a filename, Alt-G to go to DOS.
4) Now from the command-line of this DOS Shell, I do a PATH. Nope, it's the same old path as ever, not c:\moneo.
5) I think the reason that the up-front batchfile doesn't work is because I'm launching this "application" from Windows, which is exactly the idea behind all this. I need to do it this way.
6) I already tried to get into DOS from Windows via "cmd", but that generates an initial DOS Shell. Then, when I generate the second DOS Shell from my "application"; i.e. the LIST program, hardly anything works from the command-line.
You know, the reason I want to change the path, is not to have to do it manually --- it's not that long, so I guess I'll just do it manually every time. It just bothers me that this whole batchfile business doesn't work.
*****
Ok, I tried your theory.
1) I created a batchfile which set the path to C:\MONEO.
2) I executed above batchfile from Windows by going to "My Computer", selecting the above batch file, and double click to run it. The screen went black for a second so it must have run it.
3) Again from "My Computer", I select what you call "my application" which is really an old version of the LIST utility. I double click to run it, pick a filename, Alt-G to go to DOS.
4) Now from the command-line of this DOS Shell, I do a PATH. Nope, it's the same old path as ever, not c:\moneo.
5) I think the reason that the up-front batchfile doesn't work is because I'm launching this "application" from Windows, which is exactly the idea behind all this. I need to do it this way.
6) I already tried to get into DOS from Windows via "cmd", but that generates an initial DOS Shell. Then, when I generate the second DOS Shell from my "application"; i.e. the LIST program, hardly anything works from the command-line.
You know, the reason I want to change the path, is not to have to do it manually --- it's not that long, so I guess I'll just do it manually every time. It just bothers me that this whole batchfile business doesn't work.
*****