- Forum
- Windows Programming
- Making another PATH variable.
Making another PATH variable.
Hello,
I was just wondering, if it's possible to have multiple PATH variables for the same user. If so, would it cause any issues, if I'd make a separate PATH variable only for the compiler?
I don't want to mess with the one made by Windows.
Thanks
-bld
I was just wondering, if it's possible to have multiple PATH variables for the same user. If so, would it cause any issues, if I'd make a separate PATH variable only for the compiler?
I don't want to mess with the one made by Windows.
Thanks
-bld
I'm not sure what you mean by having a "separate" PATH variable. PATH is the name of an environmental variable. (Actually, there is a User variable and a System variable, both called Path. The user's Path variable is appended onto the System's Path variable. Those are your options.)
You can have other environmental variables that aren't called Path.
For example, say your compiler exe is located in C:\some\directory\path.
What you can do is add another environmental variable, say "DEV", and give it the value C:\some\directory\path.
Then, you can simply add %DEV%; to your Path variable. But still, you need to edit the Path variable, I don't think you can get around that.
If you only add another variable without editing the Path variable, you can do something almost as good, you can do:
You can have other environmental variables that aren't called Path.
For example, say your compiler exe is located in C:\some\directory\path.
What you can do is add another environmental variable, say "DEV", and give it the value C:\some\directory\path.
Then, you can simply add %DEV%; to your Path variable. But still, you need to edit the Path variable, I don't think you can get around that.
If you only add another variable without editing the Path variable, you can do something almost as good, you can do:
%DEV%\myprogram.exe
It's relatively safe to modify PATH, as long as you do so properly. I've found that 3rd-party installers modify it quite frequently.
E.g., if you create a shortcut with a target like
start_cmd.bat can contain a command which appends to PATH for the current console session only:
And set up whatever aliases you want besides.
For me this compensates for the missing RC file I expected.
E.g., if you create a shortcut with a target like
%comspec% /k d:\bin\start_cmd.bat |
set PATH=%PATH%;d:\bin |
And set up whatever aliases you want besides.
For me this compensates for the missing RC file I expected.
Last edited on
If you only add another variable without editing the Path variable, you can do something almost as good, you can do:%DEV%\myprogram.exe |
So this will work without having to modify the PATH variable?
you need that DEV entry to exist, but yes, you do not need to change PATH specifically.
let me take a crack at explaining what they said again, since you had to ask, you didn't get it.
the 'environment' is cluster of global variables that windows and the windows console (cmd, etc) can use.
the path is ONE variable in that cluster. It is not the only one, and you can make more, up to some limit (this stuff came in from dos and has some screwy limits, like path can only be like 1024 or 4096 or something like that characters long, which is a problem on some systems but there are workarounds).
you can add DEV as a variable that is NOT in the path, but still usable.
lets try it! open a console window (type cmd at the run in start menu).
type> env
and see a list of all the variables, including the path.
now lets make a variable:
type> set DEV="c:\" !!!!IMPORTANT!!!! NO WHITESPACE OR IT WILL MESS UP
type> echo %DEV%
type> cd %DEV%
The difference here is that if you do not edit path... lets say your path to your folder contains foo.exe.
if you modify the PATH, then from anywhere, any folder, in the console, if you type 'foo' it will run the program.
if you set it in another variable, you have to say %DEV%foo, which is the same as typing the path manually in front of the program name, and its clunky. you can also have the new variable do it all, set it to "c:\folder\foo.exe" and then type %DEV% and it will run the program. But those %s make this weird for actual usage, IMHO.
Another way that works is to make a small batch file in a known location that is in all paths, like c:\windows\system32 , that can run the program, foo.bat can invoke foo.exe (if you keep the same name, you need extra syntax to avoid recursive calling itself to death but its doable) and then you can type foo from anywhere, it will leech the path for foo.bat, and run foo.exe for you using the executable that isn't in the real path -- a bit of smoke and mirrors from days gone by :)
All this was said above, but with less words.
let me take a crack at explaining what they said again, since you had to ask, you didn't get it.
the 'environment' is cluster of global variables that windows and the windows console (cmd, etc) can use.
the path is ONE variable in that cluster. It is not the only one, and you can make more, up to some limit (this stuff came in from dos and has some screwy limits, like path can only be like 1024 or 4096 or something like that characters long, which is a problem on some systems but there are workarounds).
you can add DEV as a variable that is NOT in the path, but still usable.
lets try it! open a console window (type cmd at the run in start menu).
type> env
and see a list of all the variables, including the path.
now lets make a variable:
type> set DEV="c:\" !!!!IMPORTANT!!!! NO WHITESPACE OR IT WILL MESS UP
type> echo %DEV%
type> cd %DEV%
The difference here is that if you do not edit path... lets say your path to your folder contains foo.exe.
if you modify the PATH, then from anywhere, any folder, in the console, if you type 'foo' it will run the program.
if you set it in another variable, you have to say %DEV%foo, which is the same as typing the path manually in front of the program name, and its clunky. you can also have the new variable do it all, set it to "c:\folder\foo.exe" and then type %DEV% and it will run the program. But those %s make this weird for actual usage, IMHO.
Another way that works is to make a small batch file in a known location that is in all paths, like c:\windows\system32 , that can run the program, foo.bat can invoke foo.exe (if you keep the same name, you need extra syntax to avoid recursive calling itself to death but its doable) and then you can type foo from anywhere, it will leech the path for foo.bat, and run foo.exe for you using the executable that isn't in the real path -- a bit of smoke and mirrors from days gone by :)
All this was said above, but with less words.
Last edited on
bld, I would go with mbozzi's approach. It does not modify the real Path variable, it just makes a temporary one for the duration of the console run, which let's you type, for example, g++ instead of D:\mingw\bin\g++
Last edited on
^^^ that is doubly the best way. If you were, for example, running foo.exe and foo.exe needed bar.dll, it would NOT see bar.dll if you did not extend the true windows path and instead had used the DEV variable or batch file or other 'trick' to invoke foo.exe. Without the path having bar.dll pointed to, the program will not run properly, if at all.
I was trying to explain how things work, more than recommend. Extending the path, forever or for the duration of your console as you see fit, is the correct way to do it.
I was trying to explain how things work, more than recommend. Extending the path, forever or for the duration of your console as you see fit, is the correct way to do it.
| Why are you so reluctant to modify PATH? |
I've heard, that it can break stuff, if you mess it up. You know, like if you delete the default value or something. Is there a way to recover the default value?
Every process has an environment, which includes a PATH. That PATH is initially set to the system's PATH and then combined with the current user's PATH. While the PATH of each individual process can be modified, child processes inherit the parent process's environment.
You won't usually need to modify the system PATH. The system PATH lists all the directories required to boot your computer and fix any issues. The risk is fairly minimal if you modify the user's PATH instead. But, if you use the method discussed above, you won't even do that.
The method discussed above
http://www.cplusplus.com/forum/windows/272401/#msg1174797
Merely modifies the current console's process-specific environment on a temporary basis. The modification persists until you close the console.
Yeah, don't do that. If you approach the task with the correct degree of care, it's not going to happen.
To cause a serious issue, you'd need to
1.) delete the value;
2.) fail to check your work;
3.) turn off your computer before you noticed the mistake; and
4.) not have any backups.
Of course this assumes you actually made some permanent changes.
You won't usually need to modify the system PATH. The system PATH lists all the directories required to boot your computer and fix any issues. The risk is fairly minimal if you modify the user's PATH instead. But, if you use the method discussed above, you won't even do that.
The method discussed above
http://www.cplusplus.com/forum/windows/272401/#msg1174797
Merely modifies the current console's process-specific environment on a temporary basis. The modification persists until you close the console.
| You know, like if you delete the default value or something |
To cause a serious issue, you'd need to
1.) delete the value;
2.) fail to check your work;
3.) turn off your computer before you noticed the mistake; and
4.) not have any backups.
Of course this assumes you actually made some permanent changes.
Last edited on
if worried, back it up.
echo %path% > path.bak
now you have your path in a file, backed up, and you can restore it if you mess up.
clearing it out aside, order of included folders can matter as well.
echo %path% > path.bak
now you have your path in a file, backed up, and you can restore it if you mess up.
clearing it out aside, order of included folders can matter as well.
Last edited on
Topic archived. No new replies allowed.