Retrieving PATH Environment Variable

**mercury529** · 11-11-2006

Does anyone know if there is a way to read the PATH Environment Variable that the System uses in Windows XP/2k without directly reading it from the Registry? I am trying to find out if there is an API that accomplishes it.

GetEnvironmentVariable and GetEnvironmentStrings both say they retrieve the information from the environment block the program is being run under (i.e. a user), but I want to retrieve the one the System uses.

Also, does anyone know how the paths in path are enumerated when searching for a file. Is it in the order they exist in the registry value data?

Thank you very much for any information you can provide.

**OnionKnight** · 11-11-2006

Code:

#include <stdlib.h>

char* path = getenv("PATH");

**mercury529** · 11-11-2006

OnionKnight: I was under the impression that the path retrieved with getenv returns to path environment of the current environment block and not the System path (which can be different depending on how your process was created). Is that incorrect?

**Salem** · 11-11-2006

Well if something chooses to modify the environment before calling your process, there isn't a lot you can do about it.

Unless you want to reconsider your "without using the registry" condition.

**mercury529** · 11-11-2006

Salem: I am extremely comfortable with using the registry to obtain the information, I just found it odd that Microsoft has no direct API call to retrieve information that is rather essential. If there is no function, I will implement it that way, but I do not want to reinvent the wheel (and possibly be faced with changes in where the information is kept between versions of windows).

**CornedBee** · 11-11-2006

The paths are searched in the order they are in PATH. In other words, by placing a path earlier you can override later paths.

I don't see how the information here is rather essential. Your child processes inherit your environment. system() uses your process's PATH, ShellExecute(Ex) don't say anything, but I don't think they use any path at all, only the current working directory (this is my best guess based on the docs). CreateProcess is explicitely documented to not use the search path. exec() uses your process's PATH, but only in the *p variants. Same for spawn(). _popen() is incompletely documented, but if it follows the POSIX spec it behaves like system().

So unless you want to display and modify the "system PATH" as a system configuration utility, you really don't need it. And if you want to do that, messing with the registry is appropriate.

**mercury529** · 11-11-2006

CornedBee: Thank you for the info. Viewing and modifying important aspects of the OS is obviously a large part of the reason the API exists to begin with. PATH is an important part of most OS's. I just found it a little strange that I was unable to find an API function that views and modifies it.

Edit: Also, to understand what the OS will launch when something is added to the registry to launch, you must know the system path and not your evironment block path. I just found it a little odd that something that is useful is not wrapped with some API function.

By the way, were you ever on vbforums? I believe there was a CornedBee on the forums back when I programmed more heavily in VB and was on the forums. You were very helpful then too if it was you.

**CornedBee** · 11-11-2006

It was me and I'm still there. The name CornedBee is unique across the internet. (Something I'm rather proud of.)

I rather think the registry should always contain the full path to any program specified therein and never rely on PATH. Relying on PATH is always a security concern in that a malicious program might be able to place itself in a spot of low security that happens to be on the PATH before a program of the same name. Then, a system account could try to execute the program with that name and execute the malicious program instead - with full privileges. (Of course, the real security issue here is that an improperly secured directory is on the PATH of the privileged user in the first place, but you know how it works. Multiple layers of defence and all that.)

I don't agree that the default PATH is an important aspect of the OS that a dedicated API should be provided for. But whether or not I agree is not important; the fact is that no such API exists and you do have to modify the registry.

Don't forget that CURRENT_USER and LOCAL_MACHINE each have their own PATH, which get merged into the full PATH whenever a program is started by the shell.

**mercury529** · 11-12-2006

Thanks to everyone.

CornedBee: I agree completely with the PATH hijacking mechanism you described. It becomes a security hole but does exist for a reasonable purpose. As for the existence of the API, like you said, it does not really matter whether either of us thinks it should exist or not, it does not.

What I am trying to accomplish is determining what file an auto-starting location will run in the registry. To accomplish this initially I was using SearchPath to resolve the file path of entries that contained only a file name. However, this mechanism does not work because the directory the executable using SearchPath is run from takes precedence over all other locations. Also the documentation for the API is vague with how the PATH variable is acquired. Thus, the file path returned by SearchPath will not necessarily match what file is being launched by the registry. So I am attempting now to implement the technique used by SearchPath in a way that is appropriate for windows launching the file.

So my SearchPath is
1.) The System Directory (GetSystemDirectory usually System32)
2.) The 16-bit System Directory (System)
3.) The Windows Directory (GetWindowsDirectory)
4.) The PATH variable (HKLM\System\CCS\Control\Session Manager\Environment\Path)

My testing seems to confirm this is how Windows resolves the path when it automatically runs a file. I am not 100% certain, so if you know anything to the contrary, I'd appreciate the knowledge. I imagine the Current User Path is not taken into account unless something is being run from the Current User reg hive? Does CU Path have a higher or lower precedence than the Local Machine PATH variable? Thank you very much for all your help.

**mercury529** · 01-09-2007

The shell function PathFindOnPath seems to be the exact functionality I was looking for.

Thread: Retrieving PATH Environment Variable

Thread Tools

Search Thread

Display

Retrieving PATH Environment Variable

Similar Threads

(VC++ related) Unicode or Multi-byte environment?

sorting number

static class variable vs. global variable

creating class, and linking files

Path / Environment in unix