Env fails on command line arguments

Bug #1141989 reported by Jussi Pakkanen
This bug affects 2 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)

Bug Description

This simple script works fine with env:

#!/usr/bin/env python3

However if you add a command line argument to the Python 3 executable it fails:

#!/usr/bin/env python3 -tt
print('Does not work.')

The error message printed is this:

/usr/bin/env: python3 -tt: No such file or directory

This exact same piece of code does work on OSX. It should work on Linux too, as the man page says that you can pass arguments to the command:

       env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: coreutils 8.13-3.2ubuntu2.1
ProcVersionSignature: Ubuntu 3.5.0-25.39-generic
Uname: Linux 3.5.0-25-generic i686
ApportVersion: 2.6.1-0ubuntu10
Architecture: i386
Date: Sun Mar 3 13:50:47 2013
InstallationDate: Installed on 2012-09-01 (182 days ago)
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release i386 (20120817.3)
MarkForUpload: True
 PATH=(custom, no user)
SourcePackage: coreutils
UpgradeStatus: Upgraded to quantal on 2012-10-24 (129 days ago)

Revision history for this message
Jussi Pakkanen (jpakkane) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in coreutils (Ubuntu):
status: New → Confirmed
Revision history for this message
Brian Beck (brian-beck) wrote :

This is an important issue. It make applications less portable, and makes it more difficult to get applications running on a Linux server. For example, I have a fairly large Perl application that I would like to port from Macintosh OS X to Ubuntu Server. Each script begins with:

#!/usr/bin/env perl -w

So on Ubuntu, I get: /usr/bin/env: perl -w: No such file or directory

Package: coreutils
Essential: yes
Status: install ok installed
Priority: required
Section: utils
Installed-Size: 5920
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Multi-Arch: foreign
Version: 8.20-3ubuntu5
Replaces: mktemp, timeout
Depends: dpkg (>= 1.15.4) | install-info
Pre-Depends: libacl1 (>= 2.2.51-8), libattr1 (>= 1:2.4.46-8), libc6 (>= 2.15), libselinux1 (>= 1.32)
Conflicts: timeout

Let me know if there's anything I can do to help out.


Revision history for this message
C de-Avillez (hggdh2) wrote :

Thank you for opening this bug and helping make Ubuntu better.

I am unsure if this is a coreutils limitation (meaning I am pretty sure it is *not*, but not absolutely so). Although 'env' does allow for parameters to the called program, 'bash', for example, limits this usage:

(from 'info bash', chapter 3.8 "Shell Scripts"):

"if `filename' is an executable shell script. This subshell
reinitializes itself, so that the effect is as if a new shell had been
invoked to interpret the script, with the exception that the locations
of commands remembered by the parent (see the description of `hash' in
*note Bourne Shell Builtins::) are retained by the child.

   Most versions of Unix make this a part of the operating system's
command execution mechanism. If the first line of a script begins with
the two characters `#!', *the* *remainder* *of* *the* *line* specifies an
interpreter for the program. Thus, you can specify Bash, `awk', Perl,
or some other interpreter and write the rest of the script file in that

(my bolding, above.)

I do not remember this usage ever working on Linux... but it sounds to me that this would be, then, a limitation imposed by (in my example) bash, not a case of coreutils' 'env' misbehaving.

Although I cannot find a real clear explanation for 'dash', the behaviour is the same (it considers 'dash -x' -- in my tests I had "#!/build/buildd/env dash -x" as the shebang -- as a single "name".

As far as I can remember, but I may be wrong, this was enforced to limit some exploits.

Changed in coreutils (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Brian Beck (brian-beck) wrote :

After doing some research, I tend to think that C de-Avillez (hggdh2) is correct, and that it is not the env command at fault here.

However, I do think the documentation should be extended to explain or link to an explanation of the shebang line.

This is a document I found helpful: http://www.in-ulm.de/~mascheck/various/shebang/


Revision history for this message
Jussi Pakkanen (jpakkane) wrote :

This explanation makes sense and thus retargeting this bug to dash and/or bash seems like the thing to do.

Revision history for this message
C de-Avillez (hggdh2) wrote :

reassigning (at least for the moment) to bash. Resetting status to NEW.

affects: coreutils (Ubuntu) → bash (Ubuntu)
Changed in bash (Ubuntu):
status: Incomplete → New
Revision history for this message
Geir Hauge (geir-hauge) wrote :

This is a kernel limitation. It's the kernel that parses the shebang (to the shell, it's just a commented line since it starts with a # character). It's the kernel that limits the shebang line to two words. It has nothing to do with bash nor dash.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.