I need to troubleshoot some problems related to environment variables on a Unix system.

On Windows, I can use a tool such as ProcessExplorer to select particular a process and view values of each environment variable.

How can I accomplish the same thing on Unix? echoing and env cmd just show values at present time, but I want to view what values the running process is using currently.

  • 3
    Even though /proc/<pid>/environ has a size of 0, there's still information in there. "It makes more sense if you think of it as a window into the kernel. The file doesn't actually contain any data; it just acts as a pointer to where the actual process information resides." [source]
    – nevets1219
    Commented Jun 10, 2011 at 17:45

13 Answers 13

cat /proc/<pid>/environ

If you want to have pid(s) of a given running executable you can, among a number of other possibilities, use pidof:

AlberT$ pidof sshd   
30690 6512 


I totally quote Dennis Williamson and Teddy comments to achieve a more readable output. My solution is the following:

tr '\0' '\n' < /proc/<pid>/environ
  • 50
    To make it readable, convert the nulls to newlines: cat /proc/17330/environ | tr \\0 \\n Commented Sep 17, 2009 at 19:14
  • 34
    I always do xargs --null --max-args=1 echo < /proc/PID/environ
    – Teddy
    Commented Oct 29, 2009 at 13:08
  • 8
    better use strings, its fast. Cat is still faster :-) Commented Jan 14, 2012 at 19:37
  • 4
    The whole /proc filesystem isn’t portable.
    – Daniel H
    Commented Dec 16, 2016 at 16:49
  • 6
    I don't understand why using xargs to convert nulls to newlines is better than using tr. Can someone lay it out for me? Thanks. Commented May 9, 2017 at 13:55

Since this question has a unix tag and everyone else has done such a great job addressing linux tag, you can get this information on OS X and other BSD-derived systems using

ps -p <PID> -wwwe


ps -p <PID> -wwwE

and on Solaris with

/usr/ucb/ps -wwwe <PID>

Solaris also supports the /proc directory if you don't want to remember the obscure ps commmand.

  • 4
    I I run ps -p <PID> -wwwe on OS X 10.6 I get the list of all running processes. the right command is with -E flag, not -e.
    – drAlberT
    Commented Sep 18, 2009 at 8:17
  • 1
    I tested on OS X 10.4, but not 10.5. Updated accordingly. Commented Sep 18, 2009 at 15:23
  • 4
    This is not perfect. The -E option only reports the initial environment variables. If the variables have been changed by the running process itself (e.g. through the use of the POSIX putenv() function), the changes are not reflected in the output of ps -p <PID> -wwE.
    – Kal
    Commented Mar 1, 2013 at 7:11
  • 1
    Not seeing env vars of processes not owned by you sounds like a desirable feature. It is also the case for @drAlberT's Linux-oriented answer using /proc/PID/environ. Those files are only readable by the owner of the process. Commented May 9, 2017 at 13:58
  • 1
    @yani It's possible, but it's much harder, it requires attaching a debugger to the running process. See this answer: unix.stackexchange.com/a/70636
    – Kal
    Commented Jun 26, 2018 at 7:54

As others have mentioned, on Linux, you can look in /proc but there are, depending on your kernel version, one or two limits:

First of all, the environ file contains the environment as it looked when the process was spawned. That means that any changes the process might have made to its environment will not be visible in /proc:

$ cat /proc/$$/environ | wc -c
$ bash
$ cat /proc/$$/environ | wc -c

The first shell is a login shell and initially has a very limited environment but grows it by sourcing e.g. .bashrc but /proc does not reflect this. The second shell inherits the larger environment from the start, which it why it shows in /proc.

Also, on older kernels, the contents of the environ file is limited to a page size (4K):

$ cat /proc/$$/environ | wc -c
$ env | wc -c

Somewhere between 2.6.9 (RHEL4) and 2.6.18 (RHEL5) this limit was removed...

  • 1
    Is it possible to get the environmental variables of a remote process that were set after the process is spawned? I understand that on VFS, it is showed with /proc/self/environ but only if we are inside the process. But how to get this for a remote process?
    – GP92
    Commented Jan 4, 2018 at 2:36
  • Whew! Thanks for this answer hopefully still holds true. So environment variables on startup are visible to other users and processes on the system via /proc/<pid>/environ/. Run-time changes to the environment are not accessible via /proc/, but if it spawns another process the env var will end up visible in its /proc/. I guess that's why secrets should not be configured via environment variables when using containers and instead via secret files coordinated by the orchestration system or vault api.
    – jamshid
    Commented Jul 4, 2020 at 0:55

correct usage of BSD options to do this (at least on linux):

ps e $pid


ps auxe  #for all processes

and yes, ps manpage is pretty confusing. (via)

  • 1
    My Ubuntu smashes the environment variables right up against the command line, without even so much as a space between them, and also truncates to one line on the terminal window. I found ps eww $pid fixes the 2nd problem.
    – user18911
    Commented Dec 3, 2013 at 14:42
  • 1
    @user18911: The env vars have a null character separator. Other answers on this page show ways to use xargs or tr to convert these to newlines for readability. You probably realised this in the intervening four years. Commented May 9, 2017 at 14:01

While rather sparsely documented, the contents of /proc/<pid>/environ will only contain the environment that was used to start the process.

If you need to inspect the current state of a process' environment, one way to do that is by using gdb.

# Start gdb by attaching it to a pid or core file
gdb <executable-file> <pid or core file>

# Run the following script to dump the environment
set variable $foo = (char **) environ
set $i = 0
while ($foo[$i] != 0)
print $foo[$i++]
  • 1
    It could be better by putting those commands, plus a quit command in the end into a .gdb file, such as ~/penv.gdb; then starts gdb(1) with this GDB script any time when you want to exam the environment of a process, by running gdb -x ~/penv.gdb -p <pid> [<exe-file>].
    – Low power
    Commented Nov 29, 2019 at 4:41
cat /proc/PID/environ

replace PID with the PID of the process you want to see. Every information about a running process is under /proc/PID/ directory

example: cat /proc/32512/environ


Taken from the Archlinux wiki:

You can create a temporary function to parse the values in /proc/<pid>/environ. At the terminal prompt:

envof() { sed 's/\x0/\n/g' /proc/${1}/environ; }

Then with the pid of the process you want, just use:

envof <pid>

Under Linux, I'd try having a look at


For Solaris 5.10, this works:

pargs -e <PID>

And since my job makes me be an AIX fan boy, let us not forget:

ps eww [pid]

Or as the man page calls it, "Berkeley Standards".

For whatever reason, /proc/PID/environ does not exist in AIX.


If you want to create formatted env like output of the environment variables for an arbitrary process (PID), you can create a convenient bash penv <pid> command (tailored to your OS) and add it to your .bashrc:

Linux add this to your ~/.bashrc:

penv () { 
    xargs --null --max-args=1 < /proc/$1/environ

macOS / BSD add this to your ~/.bashrc:

penv() {
   ps eww -o command $1  | tr ' ' '\n'

Solaris add this to your ~/.bashrc:

penv() {
   pargs -e $1


$ source $HOME/.bashrc
$ pgrep VBoxSVC
$ penv 10268
SSH_CLIENT= 53960 22
VBOX_LOG_FLAGS=thread tsc

A mac solution, probably other BSDs as well could be something like

pid=28369; ps e $pid | cut -c$(expr 1 + $(ps p $pid|tail +2|wc -c))-

The environment variables are appended to the command line, this removes the command line and we only have the environment variables left.

It is not perfect because they are space separated not LF separated



for this, first we need to identify the PID of the process. for this you can use ps command

You must log in to answer this question.

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