Linux – Shebang Line with ‘/usr/bin/env command –argument’ Fails

envexecutablelinuxscripting

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?

Best Answer

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.

Related Solutions

The way to use `/usr/bin/env sed -f ` in shebang

You can't, portably, put more than one argument on a #! line. That means only a full path and one argument (e.g. #!/bin/sed -f or #!/usr/bin/sed -f), or #!/usr/bin/env and no argument to the interpreter.

A workaround to get a portable script is to use #!/bin/sh and a shell wrapper, passing the sed script as a command-line argument. Note that this is not sanctioned by POSIX (multi-instruction scripts must be written with a separate -e argument for each instruction for portability), but it works with many implementations.

#!/bin/sh
exec sed '
s/a/b/
' "$@"

For a long script, it may be more convenient to use a heredoc. An advantage of a heredoc is that you don't need to quote the single quotes inside, if any. A major downside is that the script is fed to sed on its standard input, with two annoying consequences. Some versions of sed require -f /dev/stdin instead of -f -, which is a problem for portability. Worse, the script can't act as a filter, because the standard input is the script and can't be the data.

#!/bin/sh
exec sed -f - -- "$@" <<'EOF'
s/a/b/
EOF

The downside of the heredoc can be remedied by a useful use of cat. Since this puts the whole script on the command line again, it's not POSIX-compliant, but largely portable in practice.

#!/bin/sh
exec sed "$(cat <<'EOF')" -- "$@"
s/a/b/
EOF

Another workaround is to write a script that can be parsed both by sh and by sed. This is portable, reasonably efficient, just a little ugly.

#! /bin/sh
b ()
{
x
}
i\
f true; then exec sed -f "$0" "$@"; fi
: ()
# sed script starts here
s/a/b/

Explanations:

Under sh: define a function called b; the contents don't matter as long as the function is syntactically well-formed (in particular, you can't have an empty function). Then if true (i.e. always), execute sed on the script.
Under sed: branch to the () label, then some well-formed input. Then an i command, which has no effect because it's always skipped. Finally the () label followed by the useful part of the script.
Tested under GNU sed, BusyBox and OpenBSD. (You can get away with something simpler on GNU sed, but OpenBSD sed is picky about the parts it skips.)

Shell – Increase %e precision with /usr/bin/time shell command

I'm assuming you understand that both these commands are calling a different version of time, right?

bash's built-in version

% time

GNU time aka. /usr/bin/time

% \time

The built-in time command to bash can be read up on here:

% help time
time: time [-p] PIPELINE
    Execute PIPELINE and print a summary of the real time, user CPU time,
    and system CPU time spent executing PIPELINE when it terminates.
    The return status is the return status of PIPELINE.  The `-p' option
    prints the timing summary in a slightly different format.  This uses
    the value of the TIMEFORMAT variable as the output format.

The GNU time, /usr/bin/time, is usually more useful than the built-in.

As to your precision problem it's covered here in this github gist, specifically:

Why is bash time more precise then GNU time?

The builtin bash command time gives milisecond precision of execution, and GNU time (usually /usr/bin/time) gives centisecond precision. The times(2) syscall gives times in clocks, and 100 clocks = 1 second (usually), so the precision is like GNU time. What is bash time using so that it is more precise?

Bash time internally uses getrusage() and GNU time uses times(). getrusage() is far more precise because of microsecond resolution.

You can see the centiseconds with the following example (see 5th line of output):

% /usr/bin/time -v sleep .22222
    Command being timed: "sleep .22222"
    User time (seconds): 0.00
    System time (seconds): 0.00
    Percent of CPU this job got: 0%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.22
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 1968
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 153
    Voluntary context switches: 2
    Involuntary context switches: 1
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

More resolution can be had using bash's time command like so & you can control the resolution:

# 3 places 
% TIMEFORMAT='%3R'; time ( sleep .22222 )
0.224

From the Bash manual on variables:

TIMEFORMAT
The value of this parameter is used as a format string specifying how the timing information for pipelines prefixed with the time reserved word should be displayed. The ‘%’ character introduces an escape sequence that is expanded to a time value or other information. The escape sequences and their meanings are as follows; the braces denote optional portions.

%%
A literal ‘%’.

%[p][l]R
The elapsed time in seconds.

%[p][l]U
The number of CPU seconds spent in user mode.

%[p][l]S
The number of CPU seconds spent in system mode.

%P
The CPU percentage, computed as (%U + %S) / %R.

The optional p is a digit specifying the precision, the number of fractional digits after a decimal point. A value of 0 causes no decimal point or fraction to be output. At most three places after the decimal point may be specified; values of p greater than 3 are changed to 3. If p is not specified, the value 3 is used.

The optional l specifies a longer format, including minutes, of the form MMmSS.FFs. The value of p determines whether or not the fraction is included.

If this variable is not set, Bash acts as if it had the value

$'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'
If the value is null, no timing information is displayed. A trailing newline is added when the format string is displayed.