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.

```bash
$ 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‐
       vironment.
```

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

**python2/python3**

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](https://askubuntu.com/questions/1065572/how-to-safely-switch-to-python3-as-default-after-upgrade-to-ubuntu-18-04), especially [this answer](https://askubuntu.com/a/475815/838537), and even more specifically from [a comment below that answer](https://askubuntu.com/questions/320996/how-to-make-python-program-command-execute-python-3#comment1773217_475815)

> 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](https://www.python.org/dev/peps/pep-0394/) 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](https://askubuntu.com/questions/1165360/why-is-python-2-7-still-the-default-python-version-in-ubuntu) - 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](https://askubuntu.com/questions/187227/i-run-sudo-apt-get-remove-python2-7-can-i-restore-my-ubuntu-now) - 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 `prog1_for_python3.py`, with the shebang line,

```python
#!/usr/bin/env python
```

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

```python
#!/usr/bin/env python

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

```

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

```bash
$ chmod a+x prog1_for_python3.py

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

$ ./prog1_for_python3.py
Press [Enter] to get out of this program ...
Traceback (most recent call last):
  File "./prog1_for_python3.py", 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.

```bash
$ 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

```bash
$ 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

```bash
unlink python
```

Now, to show things are back to normal:

```bash
$ python -V
Python 2.7.16

$ sudo python -V
Python 2.7.16
```

`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.