Is there some equivalent (CLI or GUI) to Linux's /proc/$PID/environ feature?
- 235,889
- 2,206
4 Answers
You can inspect environmental variables of running process with
ps eww <PID>
- 23,919
-
5
-
1
-
1
-
-
On 13.6.3, both
ps ewwwandps Ewwware no-go (only prints PID, TT, STAT, TIME, COMMAND), even if Isudo ps. Must be one of those securely obfuscated "security features". Gawd, they must have worked really really hard in Cupertino to make this OS even more unusable than Windows... – vladr Feb 12 '24 at 16:17
The following adds on to Mateusz's answer, pretty printing the variables one per line:
ps eww -o command <PID> | tr ' ' '\n'
- 211
- 2
- 2
-
1It's helpful and makes for a better answer if you explain what each component does. – Allan Sep 23 '16 at 23:15
-
3
-
1This doesn't work if environment variable values have spaces in them – Les Hazlewood Oct 04 '19 at 20:06
-
1@LesHazlewood: It does "work" for environment variables with spaces in them, it's just completely useless because it is impossible to disambiguate. – William Pursell Jun 28 '21 at 13:14
I have created the envps utility for this, based on Samuel's xproc code:
$ envps 607
LaunchInstanceID=5345193B
XPC_SERVICE_NAME=no.example.ExampleExtension
PATH=/usr/bin:/bin:/usr/sbin:/sbin
You can build it yourself or install it using Homebrew:
brew install henrik242/brew/envps
- 557
See the function environ_from_proc_id():
std::vector<std::string> environ_from_proc_id(NGS_PROCID proc_id)
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 example.cpp (the actual CLI code): https://github.com/time-killer-games/xproc/blob/main/example/example.cpp#L80
- 557
-
1
-
1@DanielWiddis thanks for the notification, I just fixed it. – Samuel Joseph Venable Jun 27 '21 at 05:52
-
1Excellent. 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, thenReadProcessMemoryfrom the PEB, then the ProcessParameters and finally the Environment. – Daniel Widdis Jun 27 '21 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. – Samuel Joseph Venable Jun 30 '21 at 14:30
ps eww <PID>in Terminal. – Mateusz Szlosek Jul 29 '14 at 16:40