Tag Info

Hot answers tagged

81

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


22

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


12

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


11

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.


8

This command env name=value name2=value2 program and args runs the command program and args with an environment formed by extending the current environment with the environment variables and values designated by name=value and name2=value2. If you do not include any arguments like name=value, then the current environment is passed along unmodified. The ...


6

If you don't need to pass arguments to the command then #!/usr/bin/env gawk is the way to go, however many kernels (including Linux) only accept a single argument to shebang programs. Otherwise, you can make a polyglot program that is both a shell wrapper and the awk script. Here's one for awk. #!/bin/sh true + /; exec gawk -f "$0"; exit; / {} # awk script ...


5

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


4

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


4

Shebang wasn't meant to be that flexible. There may be some cases where having a second parameter works, I think FreeBSD is one of them. gawk and most utilities that come with the OS are expected to be in /usr/bin/. In the older UNIX days, it was common to have /usr/ mounted over NFS or some less expensive media to save local disk space and cost per ...


4

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


4

Specifying the absolute path is more precise on a given system. The downside is that it's too precise. Suppose you realize that the system installation of Perl is too old for your scripts and you want to use your own instead: then you have to edit the scripts and change #!/usr/bin/perl to #!/home/myname/bin/perl. Worse, if you have Perl in /usr/bin on some ...


4

No, env is not guaranteed to be in /usr/bin, as you can read in the history of the shebang mechanism, in the section "The env utility": However, the location of env(1) might vary. Free-, Net-, OpenBSD and some Linux distributions (e.g. Debian) only come with /usr/bin/env. On the other hand, there's only /bin/env at least on SCO OpenServer 5.0.6 and ...


4

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


3

Another important use of env (apart from circumventing command alias lookup) is that it searches the PATH for the command. This is of importance where absolute paths are required, but vary from system to system. For example, beginning a Bash script with #!/bin/bash is okay, whereas #!bash isn't, despite of /bin being included in the PATH on every reasonable ...


3

Specifically for perl, using #!/usr/bin/env is a bad idea for two reasons. First, it's not portable. On some obscure platforms env isn't in /usr/bin. Second, as someone else has noted, it can cause trouble with passing arguments on the shebang line. The maximally portable solution is this: #!/bin/sh exec perl -x $0 "$@" #!perl For details on how it ...


2

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


2

pgrep doesn't parse ouput of ps, it will look through /proc/<PID>/status and /proc/<PID>/cmdline to finding matching for given pattern. Do some strace: getpid() = 6572 stat("/proc/self/task", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 openat(AT_FDCWD, "/proc", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 ...


2

Q#1 Why does the name of the script not show up when called through env? From the shebang wikipedia article: Under Unix-like operating systems, when a script with a shebang is run as a program, the program loader parses the rest of the script's initial line as an interpreter directive; the specified interpreter program is run instead, passing ...


2

Run your script with env -i: env -i script.sh And the script as usual: #!/bin/sh # ... your code here If you mean to run with a clean environment without explicitly say that when you run. Eduardo Ivanec gives some ideas in this answer, you can recursively call your script with exec when the environment is not clean (e.g. $HOME is defined): [ "$HOME" ...


2

Gilles' proposed solution is indeed a very good approach (tried to vote on it and comment, but since I just joined, I don't have enough reputation to do both). In any case, as far as I understand the exec command, it makes the exit right after it unnecessary, actually unreachable, as the shell process is replaced out by awk. In addition, in order to allow ...


2

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.


2

You seem to be somewhat confused about what is a shell variable and what is not. All the variables in your post are environment variables, not shell variables. To set a shell variable: foo=bar To set an environment variable: export FOO=BAR (or setenv in c shells). But in FOO=BAR command the assignment counterintuitively has a different meaning than ...


1

OK..So I found the solution. Here is what I was doing :- 1) vi ~/.bash_profile 2) make changes3) source ~/.bash_profile to see those changes in effect . It seems for every editing and subsequent source command, temporarily keeps in current session. So , if i made changes 3 times and consequent source command, it shows 3 times the same path if i do echo $PATH ...


1

Duplicate paths won't hurt anything. There likely is a script somewhere that is overwriting the path variable. Try the following to narrow down where the variable is being set. See if there is an environment variable overwriting the path logout + log back in echo $PATH See if a fresh shell has the same path set sudo su foo - echo $PATH See if ...


1

Boot with the FreeBSD install media. You will be prompted for <Install> < Shell > <Live CD> Select <Live CD> From there you will get a shell and can mount your drives (gpart list) and do what you need to. It's odd that you didn't get the freebsd boot code though as the install would normally put it there for you if you use the ...


1

I've never used BSD before, but this shouldn't be too complicated. All that is necessary is to boot your livecd, mount the partition you installed on and chroot to the mount point. This should be as simple as: su mount /dev/da0s1 /mnt chroot /mnt You will have to find the correct partition you installed on, fdisk -s should help with that (appears to be ...


1

The reason this does not work is because it sees -i /bin/sh as a single argument to env. Usually this would be 2 arguments, -i and /bin/sh. This is just a limitation of the shebang. No way around it. However you can still perform this task, just a different way. If you want this task to be performed by the script itself, and not have to do something like ...


1

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


1

env is trying to find a file with name "sed -f". You can try "#!/usr/bin/sed -f" as your shebang line.


1

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



Only top voted, non community-wiki answers of a minimum length are eligible