Env fails on command line arguments

[Jussi Pakkanen]

This simple script works fine with env:

#!/usr/bin/env python3
print('Works')

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:

SYNOPSIS
       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 3.5.7.4
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
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: coreutils
UpgradeStatus: Upgraded to quantal on 2012-10-24 (129 days ago)

[Launchpad Janitor (janitor)]

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

[Brian Beck (brian-beck)]

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.

Cheers,
Brian

[C de-Avillez (hggdh2)]

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
language."

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

[Brian Beck (brian-beck)]

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/

Thanks,
Brian

[Jussi Pakkanen (jpakkane)]

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

[C de-Avillez (hggdh2)]

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

[Geir Hauge (geir-hauge)]

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.