Shebang line with `#!/usr/bin/env command --argument` fails on Linux

Question

I've got a simple script:

#!/usr/bin/env ruby --verbose
# script.rb
puts "hi"

On my OSX box, it runs fine:

osx% ./script.rb
hi

However, on my linux box, it throws an error

linux% ./script.rb
/usr/bin/env: ruby --verbose: No such file or directory

If I run the shebang line manually, it works fine

linux% /usr/bin/env ruby --verbose ./script.rb
hi

But I can replicate the error if I pack ruby --verbose into a single argument to env

linux% /usr/bin/env "ruby --verbose" ./script.rb
/usr/bin/env: ruby --verbose: No such file or directory

So I think this is an issue with how env is interpreting the reset of the shebang line. I'm using GNU coreutils 8.4 env:

linux% /usr/bin/env --version
env (GNU coreutils) 8.4
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Mlynarik and David MacKenzie.

This seems really odd. Is this a common issue with this version of env, or is there something else going on here that I don't know?

Answer 1

Looks like this is because Linux (unlike BSD) only passes a single argument to the shebang command (in this case env).

This has been extensively discussed on StackOverflow.

Answer 2

Found this via @rampion comment:

What happens is that the kernel processes the first two characters of the file looking for #!. If those are found then it skips all space characters looking for a non-space character and extracts the interpreter path which must be a real executable and not another script, although linux extends that to allow recursive script processing. Having found that then it skips to the first non-space character where it takes from there to the next newline character and passes that as a single argument to the command. There is no 'shell' processing of quotes or other meta characters. It is all very simple and brute force. Therefore you cannot get fancy with options there. You get exactly one argument white space included and 'perl -w' is what the kernel sees here and passes on.

Source: http://lists.gnu.org/archive/html/bug-sh-utils/2002-04/msg00020.html

Answer 3

Coreutils>=8.30:

#!/usr/bin/env -S ruby --verbose

The -S or --split-string env option is documented in the GNU coreutils manual (see: info '(coreutils) env invocation' or the online manual). Below is an excerpt:

Most operating systems (e.g. GNU/Linux, BSDs) treat all text after the first space as a single argument. When using env in a script it is thus not possible to specify multiple arguments.

In the following example:

#!/usr/bin/env perl -T -w print "hello\n";

The operating system treats perl -T -w as one argument (the program's name), and executing the script fails with:

/usr/bin/env: 'perl -T -w': No such file or directory

The -S option instructs env to split the single string into multiple arguments. The following example works as expected:

$ cat hello.pl
#!/usr/bin/env -S perl -T -w print "hello\n";

$ chmod a+x hello.pl $ ./hello.pl hello

and is equivalent to running perl -T -w hello.pl on the command line prompt.