Tag Info

It isn't necessarily better. The advantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user's $PATH. The disadvantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user's $PATH. That means that the script could behave differently depending on who runs it. For ...

Because /usr/bin/env can interpret your $PATH, which makes scripts more portable. #!/usr/local/bin/python Will only run your script if python is installed in /usr/local/bin. #!/usr/bin/env python Will interpret your $PATH, and find python in any directory in your $PATH. So your script is more portable, and will work without modification on systems ...

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

Linux (you mentioned "only under Ubuntu" but the only OS you mentioned it working under was Darwin) does not support passing multiple arguments to a 'shebang' interpreter. It passes the entire string (in your case, "zsh -") as a single argument. The correct way to ensure your package does not depend on the location of an interpreter is to, as part of the ...

I think the answer to your question is basically "no". The shebang mechanism just isn't that flexible. The #! line only lets you specify a command to execute, and (optionally) a single argument to that command. The name of the script is passed as another argument. So if foo.zsh starts with: #!/usr/bin/env zsh the running foo.zsh is equivalent to ...

There are various incompatible implementations of the shebang (#!) depending on the OS. Some are building a full argument list, some are preserving the command path and put all remaining arguments as a single one, some are ignoring all of the arguments and pass only the command path, and finally, some are passing the whole string as a single command. You ...

The short answer is that you can't. The idea behind using #!/usr/bin/env ruby instead of simply #!/usr/bin/ruby is to use whatever ruby binary is first in the user's path. Then your script doesn't depend on ruby being in the same place on every system; after all, a 'normal' ruby location might be /usr/bin/ruby, /usr/local/bin/ruby, /opt/ruby-1.8.7/bin/ruby, ...

Firstly, chmod a-r bin/python does not prevent python to remove files. It prevents anyone not owner or not in the correct group to read that file. If you wish to run unsafe code in a "jail", I suggest using chroot jail. Bear in mind that in order for chroot to run effectively, python executable should not be ran under root privileges.

Functions are naturally propagated to subshells: greet () { echo "hello, $1" } ( echo "this is a subshell"; greet bob ) But they are not and cannot be propagated to independent shell processes that you start by invoking the shell under its name. Bash has an extension to pass functions through the environment, but there's no such thing in other shells. ...

Adding another example here: Using env is also useful when you want to share scripts between multiple rvm environments for example. Running this on the cmd line, shows which ruby version will be used when #!/usr/bin/env ruby is used inside a script: env ruby --version Therefore, when you use env, you can use different ruby versions through rvm, without ...

Actually, chmod a-r bin/python prevents the file's owner, those in the file's group, and all other users from reading the file (except the superuser of course). chmod o-r bin/python would prevent all users except the owner and those in the file's group from reading the file. The file permissions of an executable do not affect its ability to read or edit ...