27

Is there some equivalent (CLI or GUI) to Linux's /proc/$PID/environ feature?

1
32

You can inspect environmental variables of running process with

ps eww <PID>
3
  • 3
    Is there a way to pretty print this afterwards? Jul 4 '16 at 21:48
  • I'm on macOS 10.14.4 and this doesn't work for me :(
    – Tran Triet
    Sep 23 '19 at 11:14
  • 1
    It works for me on macOS 10.15.1
    – Andrew
    Dec 5 '19 at 1:53
13

The following adds on to Mateusz's answer, pretty printing the variables one per line:

ps eww -o command <PID>  | tr ' ' '\n'
4
  • 1
    It's helpful and makes for a better answer if you explain what each component does.
    – Allan
    Sep 23 '16 at 23:15
  • 1
    If you're curious, explainshell can break this down. Dec 11 '18 at 0:35
  • 1
    This doesn't work if environment variable values have spaces in them Oct 4 '19 at 20:06
  • @LesHazlewood: It does "work" for environment variables with spaces in them, it's just completely useless because it is impossible to disambiguate. Jun 28 at 13:14
0

See the function EnvironFromProcId():

https://github.com/time-killer-games/xproc/blob/main/crossprocess.cpp

void EnvironFromProcId(PROCID procId, char ***buffer, int *size)

From the specified PROCID, (typedef for DWORD / unsigned long on Windows, otherwise pid_t / int for Mac, Linux, and other Unix-likes), the function shall copy a vector of environment strings (NAME=VALUE) to 'buffer', and the amount of strings shall be copied to 'size'. This function is not thread safe, however the source may be modified so that it can become thread safe. Note that this uses an incompletely-documented structure on Windows, and in order for it to be able to read the environment block between (to and from) both 32-bit and 64-bit processes, it uses a method that is not as performant as the other platforms. It is built with secondary executables compiled directly into the initial one, which gets extracted to the Windows temp directory at runtime, and runs from there. Depending on the architecture of the target process's associated executable image, that will determine the architecture of the secondary executable to run. Wrote for Windows, Mac, Linux, and FreeBSD. Ubuntu / Debian needs libprocps-dev, also libx11-dev if compiled using the build*w.sh build scripts which include windowing code, (not the default). FreeBSD will need libX11 if built with windowing.

Or, compile from the source code using the build scripts (MinGW / g++ on Windows / Linux, clang on Mac / FreeBSD), then run from the command line passing the --env-from-pid pid command line parameters. Pass the --help parameter for the list of all possible options.

For convenience, example usage is in main.cpp (the actual CLI code): https://github.com/time-killer-games/xproc/blob/fe14ec70e4e58359ddf3d29aa03c86328c97b49b/main.cpp#L153

4
  • 1
    Link no longer works. Jun 26 at 22:46
  • 1
    @DanielWiddis thanks for the notification, I just fixed it. Jun 27 at 5:52
  • 1
    Excellent. Useful link, confirms information I've seen elsewhere but is more easily digested. I'd suggest you update your answer to highlight the key steps the code does (Call NtQueryInformationProcess, then ReadProcessMemory from the PEB, then the ProcessParameters and finally the Environment. Jun 27 at 17:50
  • @DanielWiddis this is technically the Apple stack-exchange, so I didn't want to go too far off topic with other platform solutions, but perhaps if I get another person giving me the OK, perhaps a staff member, I'll gladly add more details for the Windows-specific approach. I've already given a lot of off-topic info otherwise I'd do it now. Jun 30 at 14:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .