I think it better to read the source code to find out whether the OS
PATH variable persists through a clearing of environment – Tracy
Reading the source code would of course give all information about the matter. But we can also obtain valuable clues by using strace
:
>strace -eexecve env -i ls
execve("/usr/bin/env", ["env", "-i", "ls"], [/* 48 vars */]) = 0
execve("ls", ["ls"], [/* 0 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/ls", ["ls"], [/* 0 vars */]) = 0
We see that env
tries executing "ls"
without a path first, which fails, and then tries executing "/bin/ls"
, which succeeds. We also see it start with an empty environment [/* 0 vars */]
.
>strace -eexecve env -i foo
execve("/usr/bin/env", ["env", "-i", "foo"], [/* 48 vars */]) = 0
execve("foo", ["foo"], [/* 0 vars */]) = -1 ENOENT (No such file or directory)
execve("/bin/foo", ["foo"], [/* 0 vars */]) = -1 ENOENT (No such file or directory)
execve("/usr/bin/foo", ["foo"], [/* 0 vars */]) = -1 ENOENT (No such file or directory)
env: foo: No such file or directory
When specifying a non-existent command or a command residing in some other path, we see that env
finally tries the /usr/bin/
path, and that's it. So, obviously /bin/
and /usr/bin/
are hardcoded in env
, and with -i
the command's environment is indeed empty. Another test:
>env -i strace ls
strace: ls: command not found
If ls
is to be executed not directly by env -i
, but indirectly thru another command, it is not found.