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

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

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?

  • 4
    relevant? – rampion Feb 6 '13 at 20:21
  • Same here with coreutils 8.17. Weird. Reporting to Fedora, as this goes explicitly against what the manual says. – vonbrand Feb 6 '13 at 20:32
  • @vonbrand What did Fedora say? "We don't care." – cat May 1 '16 at 12:43

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.

  • 3
    see also this page for a review of the behaviour on different Unices. – Stéphane Chazelas Feb 6 '13 at 20:46
  • 3
    Specification fail. My god. – Konrad Rudolph Dec 4 '14 at 17:09
  • 2
    If by "specification fail" you mean all Unix systems should accept more than 1 argument, then I 100% agree with you :) – Alexander Mills Mar 25 '17 at 0:01

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.