UNIX for Advanced & Expert Users

hi i have some perl scripts with shebang line as (#! /usr/bin/env perl ) instead of actual absolute path of perl ( i know why its that way ) everything works fine from command line , the problem is when i am trying to run those scripts from web ( local web tool ) it throws error as

Code:

/usr/bin/env : perl No such file or directory

even when i logged in to web user i tried to run it it was okay .... i googled for it but not getting answers only suggestions to change it to absolute path which i dont want to do. any suggestions ??

What is env? What you have is a shebang where perl is some kind of parameter or option. I'm guessing you find perl because it is in your PATH when you are logged on. a more standard shebang would be

Code:

/usr/bin/env/perl

assuming this actually points to the location of the perl exectuable.

It because the perl interpreter is not in the search path of the user that owns the web server process.
You could consider:

1. Modifying your shebang (to point directly to the perl interpreter), for example:

Code:

#!/usr/bin/perl

or

2. Adding the perl interpreter's directory to the search path to the user that owns the web server process and continue to use the env program:

Code:

#!/usr/bin/env perl

yup you are right...
PATH variable was not passed to fastcgi when starting a apache as it was not in path it used to throw error. just passed the variables now its working ..
thanks a lot

Fun Perl Fact:

I would like to "dig" the subject a little bit more, because I have also problem with script using that way of shebang.
I have installed, on Solaris, system wide, Perl 5.8.7 and the script that uses env tool to launch perl interpreter looks for LibXML.pm in folders where used to be installed perl 5.8.4.
So i have two questions:
1. why one would use env tool to launch perl instead of launching perl directly?
2. how to modify the env's output?

You could need to call it that way when you don't have control over the owner of the apache process and/or
you want to use the same configuration file on more non identical systems.

If the above is not true just modify the environment of the owner of the apache process and point directly to the desired Perl interpreter.

You will use /usr/bin/env ... when you are not sure where exactly the needed executable is located, but you're sure it can be found somewhere in the environment.

Hi.

These are good questions, and it is useful to know the issues. As radoulov has written, the env in the shebang line

Code:

#!/usr/bin/env bash

promotes portability. I use that in a template for writing scripts because I use several environments, and the locations of bash, ksh, perl, etc., are not consistent. This is often true for posting scripts here in this forum because the questions do not always mention the environment, Linux, Solaris, AIX, etc., so I almost always use that for suggested solutions. The Linux documentation for env leaves much to be desired in my opinion. For more information on many subjects including the use of env, see "bash Cookbook", O'Reilly, page 321.

However, we need to balance portability and security. If you have a consistent environment, then, for bash scripts, the construct

Code:

#!/bin/bash -

will avoid certain security risks. See "bash Cookbook", page 283. The authors consider the risks of the env construct to be small, so I generally stay with that.

Best wishes for safety and portability ... cheers, drl