How do you include %ProgramFiles% in PATH? - windows

According to this post it is not possible to include %ProgramFiles% in the path varaible, because windows environment variables get resolved in alphabetical order.
However, I need to be able to get the correct location of program files in PATH from a batch file (it can be expanded, I just can't hardcode the drive letter into the batch file because it needs to be portable). How do I do this?
EDIT: In response to some of the comments below, here is some additional information:
-The change to PATH needs to be permanent.
-SETX appears to just stick the literal %programfiles% in the path variable.

You can't get %ProgramFiles% expanded when hand editing the PATH from the Control Panel System applet at system level.
But you can certainly use %ProgramFiles% in your BAT file. Just try
PATH %ProgramFiles%;%PATH%
If you want a permanent change in your PATH from a BAT file, then that's another question, already answered here Permanently altering a user's %PATH% environment variable via batch or Python

Related

Location of Command Prompt Commands

Where are the commands located for Command Prompt? I know this is possible in Linux, but what about windows?
I want to rename certain commands so I can make my own using the original name.
Im doing this on a 32bit Windows XP if that helps.
More specifically, where can I find the tree command?
https://superuser.com/questions/312926/windows-equivalent-of-which-command-in-linux
in windows 7 there's the where command.
You can overwrite the standard commands, but this will break a lot of stuff.
You would also have to modify your path environment variable
in windows 7 tree is located in C:\Windows\System32\tree.com
This might be a useful site for you
http://ss64.com/nt/
Use a bat file of the same name to override an inbuilt external command. Some commands are internal so you have to specify .bat. Also if calling the overridden program specify the extension.
There are two types of commands in Windows command prompt. The internal commands are built-in inside the command processor program, that is called cmd.exe. You may inspect such commands if you open cmd.exe file with an Hex editor, or even directly with Notepad (although doing that requires a lot of patience!); to know the location of cmd.exe file, type: set comspec. Examples of internal commands are DIR, COPY, TYPE, MD, etc. (the simplest ones) and all Batch-file commands, like GOTO, IF, FOR, REM, etc. There is no way to change the name of an internal command, unless you modify the cmd.exe file (for example, using the same Hex editor) that, although possible, is NEVER recommended!!!
The external commands reside in disk files with .com or .exe extension that are grouped in certain subdirectories, usually in C:\Windows\System or C:\Windows\System32; these subdirectories must appear in %PATH% variable in order to execute the external commands directly in the command prompt. You may locate the folder where an executable file resides using the following command, that review folders included in PATH variable only (you can not use wild-cards in this case):
for %a in (tree.com tree.exe) do #echo/%~$PATH:a
You may directly change the name of any command-name.exe file; however, this practice is not recommended. A simpler option is create a Batch file with the same name of a standard command (and .bat extension) and place it in a folder that will be included in PATH variable before the standard commands folder (or in the current directory). For example, create a file named tree.bat and place it in C:\Users\MyName\MyCommands; then, modify PATH variable this way: path=C:\Users\MyName\MyCommands;C:\Windows;C:\Windows\System32. If you need to use the standard tree command inside your tree.bat file, just include the proper extension: tree.com.

System versus user PATH environmental variable...winmerge works only if I add the path to the user PATH

If I add C:\Program Files (x86)\WinMerge to the User PATH variable(by right click on computer -> advanced system settings -> environmental variables), once I open a new cmd shell WinmergeU.exe is not recognized. If I add that path to the System PATH variable, WinmergeU.exe is correctly recognized instead. I though there was no difference between User and System, beside the fact that if I set it on System all the users will see it, while the User PATH is local. Am I doing something wrong?
EDIT 1:
In the follow you can see first the case in which C:\Program Files (x86)\WinMerge is added to the System PATH variable (but not to the User), then when it is added to the User PATH variable (but not to the System). In the first case Winmerge window launch correctly (not shown) and as you can see the path is shown by the echo %PATH% command. In the second case it does not launch and the path it is not shown by echo %PATH%. (note that I clearly confirmed with OK and closed the environmental variable windows before taking these screenshots, and I opened a new cmd right after changing PATH and pressing ok). This issue might be related to my question here (Does echo %PATH% expand to only the system or also the user variables?) but since it might not be I posted two different question.
You must be getting something wrong, or have environmental problems with your machine. Adding a user PATH environment variable does result in it being merged into the environment of a new process.
Update: Perhaps this comment from the MSDN topic on environment variables might be pertinent:
Found out that on Windows Server 2003, once the system PATH passes 1920 characters, the user PATH environment variable is no longer merged with it to set the process PATH environment variable, even though the full system PATH (even if larger) will be included in the process PATH variable.
On Windows 7, also make sure that the system path does not end with a backslash. If it does, the USER PATH is appended to the system path as per usual, but after a line break, which breaks things. In the latter case, the simple command "path" and "echo %PATH% " will print 2 different outputs.
For 16.6, I've confirmed this issue to be a path length issue as well. At a cmd prompt, typing 'set', you can see all of the env. variables. The user path cadence variables and others weren't included. I saved the original complete path text, then I went through and trimmed specific (system) path elements that were deemed unnecessary. after this, in a new cmd session, typing 'set' now shows the user path elements tacked on to the end of the system path elements, because they now fit.

Windows batch scripting - where to put a .bat such that it can be called from anwhere?

I know how to do this with a bash script on *n*x - by placing it in /usr/bin or /usr/local/bin.
Where in the Windows (7) file system should I place a .bat such that it can be called from any directory I'm in on the command line?
Thanks
In some directory that is mentioned in your PATH environment variable. Actually that's exactly the same as in Unix-like systems.
Mind you, it's probably easiest to just create a directory for that and add it to PATH than throwing them in random locations where they don't belong (such as system32).
You need to either put it in a location in the PATH variable or create a new one in there.
You can do this in Windows (Vista and above, probably similar in XP) by right clicking Computer => Properties => Advanced System Settings => Advanced => Environment Variables.
Find the PATH variable, and either add your batch file to a path in there or add a new path of your choice separated from the others with a semi colon ;.

Where can I store a batch file so it runs anywhere on my computer?

I created a really small batch file that I want to be able to call anywhere in my command-line environment by name:
So if my batch file is hi.bat, I want to type hi in the command window and have it run. Where can i store the batch file so this happens?
Thanks
Store it somewhere in the PATH or have PATH include its directory. The PATH variable contains a list of directories that are searched when you enter a command. Depending on your version of windows, you can change environment variables from My Computer -> Properties or Advanced System Settings.
If you have the permissions, just modify the PATH environment variable to include the folder which hi.bat is in. You can then place hi.bat anywhere you want.

How to create a path to a temporary file on Windows XP/Vista

What is the best way of doing this?
tmpnam() returns a path to a file in the root of the drive, which requires administrator privileges on Windows Vista, so this is not an option.
GetTempPath and GetTempFileName should work.
The environment variable %TEMP% on Windows points to the users temp directory.
In managed C++ you can call Path::GetTempFileName() which will give you a temporary file in the users temp directory (which can be found using Path::GetTempPath() ). GetTempFileName() basically just gives you a path to a file in the %TEMP% path using a GUID as the file name. You then use that path to create the file and do what you want with it. You could do similar logic in any language that has access to the current processes environment variables.
Hope that helps,
Martin.
Have you tried with the environment variables TEMP and TMP set to a directory writable by all?
To change environment variables in XP (not familiar with Vista), you go to System Properties, [Advanced] tab, [Environment Variables] button.
Perhaps you could use the Win32 method GetTempPath() in kernel32.dll. This is wrapped in .NET by System.IO.Path.GetTempFileName().
On XP this returns a path in C:\Documents and Settings\username\Local Settings\Temp\, so you should not require admin privileges.
If you care about interoperability, the man page for tmpnam suggests:
tmpnam man page
BUGS
Never use this function. Use mkstemp(3) instead.
mkstemp man page
SYNOPSIS
#include <stdlib.h>
int mkstemp(char *template);
DESCRIPTION
The mkstemp() function generates a unique temporary file name from template. The last six characters of template must be
XXXXXX and these are replaced with a string that makes the filename unique. The file is then created with mode read/write
but all these suggest that you have prepared your template prefixed by the contents of the TMP environment variable.

Resources