I ran into some issues when running some installation scripts where they complained of bad interpreter.

So I made a trivial example but I can't figure out what the problem is, see below.

#!/usr/bin/env bash
echo "hello"

Executing the script above results in the following error

[root@ech-10-24-130-154 dc-user]# ./junk.sh
bash: ./junk.sh: /usr/bin/env: bad interpreter: No such file or directory

The /usr/bin/env file exists, see below:

[root@ech-10-24-130-154 dc-user]# ls -l /usr/bin/env
lrwxrwxrwx 1 root root 13 Jan 27 04:14 /usr/bin/env -> ../../bin/env
[root@ech-10-24-130-154 dc-user]# ls -l /bin/env
-rwxr-xr-x 1 root root 23832 Jul 16  2014 /bin/env
[root@ech-10-24-130-154 dc-user]#

If I alter the script to use the regular shebang #!/bin/bash it works no problem. #!/bin/env bash works as well.

What is missing from the environment to allow the portable shebang to work?

ls -lL /usr/bin/env returns ls: cannot access /usr/bin/env: No such file or directory so I guess I need to alter the symbolic link? Can I point it to /bin/env?

env --version is 8.4 and the OS is Red Hat Enterprise Linux Server release 6.6.

  • 1
    Usually that's due to carriage-return/line-feed endings on the lines. Alternatively: location of env. Commented Jan 27, 2016 at 10:27

3 Answers 3


ls -lL /usr/bin/env shows that the symbolic link is broken. That explains why the shebang line isn't working: the kernel is trying, and obviously failing, to execute a dangling symbolic link.

/usr/bin/env -> ../../bin/env is correct if /usr and /usr/bin are both actual directories (not symlinks). Evidently this isn't the case on your machine. Maybe /usr is a symbolic link? (Evidently it isn't a symbolic link to /, otherwise /usr/bin/env would be the same file as /bin/env, not a symbolic link).

You need to fix that symbolic link. You can make it an absolute link:

sudo ln -snf /bin/env /usr/bin/env

You can make it a relative link, but if you do, make sure it's correct. Switch to /usr/bin and run ls -l relative/path/to/bin/env to confirm that you've got it right before creating the symlink.

This isn't a default RHEL setup, so you must have modified something locally. Try to find out what you did and whether that could have caused other similar problems.

  • This is correct, /usr/bin was moved to another file system and is a symbolic link to /vol_01/usr/bin Commented Jan 28, 2016 at 9:24
  • @conorgriffin: What OS was that, please?
    – saulius2
    Commented Jan 15 at 11:40
  • It's in the question :) "env --version is 8.4 and the OS is Red Hat Enterprise Linux Server release 6.6." Commented Jan 19 at 20:46

So... I was getting a similar error but for /usr/bin/sh not being found and was also telling me the script I was trying to run was not found as I am running it! I verified location of sh in /usr/bin so was baffled and came here looking for answers...

In my case, I was editing in UltraEdit and forgot to convert the DOS CR LF's to Unix LFs. DOH!

Once I did that and re-imported script it found sh just fine. I had other issues to work out but this mystery issue was solved.


Here (Fedora 23) /bin is a symbolic link to /usr/bin; if you have a similar setup, the symbolic link from /usr/bin/env just buys you an infinite loop.

Check the relevant packages, i.e. rpm -qf /usr/bin/env /bin/env, and reinstall those (here coreutils, i.e.. yum reinstall coreutils or similar). That should fix any misguided manhandling.

  • I already reinstalled coreutils but that made no difference. It's pretty weird. /usr/bin/env is a symbolic link with a relative path to it's target ../../bin/env. So that should be /bin/env which also exists. So I don't understand why that symbolic link doesn't work. I replaced the target so it points to /bin/env with an absolute path and that seems to have worked. Commented Jan 27, 2016 at 11:15
  • If /bin was a symbolic link to /usr/bin on conorgriffin's system, then /usr/bin/env and /bin/env would be the same file. Commented Jan 27, 2016 at 22:10

You must log in to answer this question.

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