shell linux macos aix add tag
I'm rewriting some existing code and noticed that a shell call to `env` (without arguments) is wrapped in error trapping code. Now I'm curious, under what circumstances could `env` conceivably fail?

The code is intended to run under AIX, macOS X, and all Linux distros, including Raspbian.
Top Answer
This answer gives an example where `env` would fail _with_ arguments. If that makes it irrelevant, feel free to remove the answer. Below, I talk about python2/python3, but

**I do want to note** the following:

I think that the answer by @Jack shows something which would more appropriately be called an actual “failure” of `env`, especially the kind of failure that interests the OP. A call to `env` in the situation of `/usr/bin/env` not existing won’t do _anything_ related to what it’s supposed to do - it will just cause an error, specifically: `-bash: env: command not found` . I imagine the OP was looking more for this type of failure, since it would make more sense to call `env` (without arguments) in error trapping.

$ export MANWIDTH=70 && man env | grep "env \[" && echo && \
> man env | grep -A 1 "no COMMAND" && echo
       env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]

       A mere - implies -i.  If no COMMAND, print the resulting  en‐

As we can see from the `man` page for `env`, using it without arguments is a good way of seeing what in the environment might have caused an error.

I hope this will encourage people who are looking for `env` as it might be used in error trapping


I don't know exactly what you mean by "fail", but one thing immediately came to my mind after reading this question:

setting `python` to point to a version of `python3` (e.g. `/usr/bin/python36`)

A good reference (with a specific discussion of `env`) comes from [here](, especially [this answer](, and even more specifically from [a comment below that answer](

> Aliases are internal to Bash, not part of the environment.

The *failure* here could be anything from unexpected behavior to causing a large part of an underlying OS not to work, depending on whether the change is implemented by an alias or by changing the symbolic linking.

[PEP 394]( suggested

> The `python` command should always invoke Python 2 (to prevent hard-to-diagnose errors when Python 2 code is run on Python 3).

One should be aware of the issues discussed in [this post]( - arch linux having `python` point to `python3`, Ubuntu trying to get everyone writing in `python3`, etc. - and I've had experiences such as that described in [this seven-year-old post]( - where a lot of the Ubuntu OS depends/depended (Wall of Shame/ Wall of Superpowers) on `python2` and thus `python` referring to `python2`. Detailed discussions, I'm sure, can be found elsewhere, and I'm not putting an opinion forward; I just want to use it as an example of an `env` "failure".

**alias issues**

With `alias python=/usr/bin/python3`, whether it be from the `bash` terminal or from something like `~/.bashrc`, there can be some "failures".

In a script, we have one main `env` failure. Consider someone who had set that alias in `~./bashrc` or straight from the terminal, then written a (`python3`) program, let's call it ``, with the shebang line,

#!/usr/bin/env python

could be surprised by unexpected behavior. Let's say the whole script were

#!/usr/bin/env python

input("Press [Enter] to get out of this program ...")


After setting the script executable with a `chmod a+x`, such a person might be confused by the differing output that follows.

$ chmod a+x

$ python
Press [Enter] to get out of this program ...

$ ./
Press [Enter] to get out of this program ...
Traceback (most recent call last):
  File "./", line 3, in <module>
    input("Press [Enter] to get out of this program ...")
  File "<string>", line 0

SyntaxError: unexpected EOF while parsing

Once again, here, "failure" means "unexpected result". The problem here is that scripts do not inherit the `alias`es for the session. This is illustrated by the following two commands and outputs.

$ ls -lah /usr/bin/python
lrwxrwxrwx 1 dblack domain users 22 Jul 14 09:25 /usr/bin/python -> /usr/bin/python27

$ type python
python is aliased to `/usr/bin/python3'

To be more complete, we could also see

$ ls -lah /usr/bin/python3
lrwxrwxrwx 1 bballdave025 domain users 14 Dec  3  2019 /usr/bin/python3 -> python36

I imagine that some failures with `env` could also happen if one were to change the `/usr/bin/python` symbolic link to point to `/usr/bin/python36`, but I just want to leave the one example that I know has caused problems before.

(By the way, another non-`env` problem could come from using `sudo`, e.g. `python -V` would give `Python 3.6.9`, while `sudo python -V` would give `Python 2.7.16`)

For anyone who has been following along with these steps, you probably want to change back to whatever situation you had before, e.g. for me

unlink python

Now, to show things are back to normal:

$ python -V
Python 2.7.16

$ sudo python -V
Python 2.7.16
Answer #2
Jack Douglas
`env` isn't a builtin, so a shell call to `env` will fail if the executable does not exist for some reason.

::: tio S0oszvj/v6SyIFUhNa/s/38A
§§§ bash bash
type env
``` none
env is /usr/bin/env

I can imagine that some ancient (pre v5) version of AIX could be missing the `env` binary.

Enter question or answer id or url (and optionally further answer ids/urls from the same question) from

Separate each id/url with a space. No need to list your own answers; they will be imported automatically.