# creating shell scripts using #!/usr/local/env perl - Page 2

•  Subject
• Author
• Posted on

## Re: creating shell scripts using #!/usr/local/env perl

On 02 Aug 2004 22:57:03 GMT, wrote:

>Paul Lalli (mritty@gmail.com) wrote on MMMCMLXXXIX September MCMXCIII in
>^^
>^^  All your 'cute' shebang is doing is calling 'perl' using the default
>^^  current environment, that is, without modifying the environment at all.
>^^  This is useful for transporting perl scripts from one machine to another,
>^^  where it's possible the 'correct' perl to use is in, say, /usr/local/bin
>^^  rather than /usr/bin.   This way, you will always call the instance of
>^^  perl that would be called if you simply typed 'perl' at the shell prompt,
>^^  rather than hardcoding a location.
>
>
>\begin
>
>Yes, and the gain of not having to hardcode the path to perl comes
>with the price of having to hardcode the path to env.
>
>\end
>
>
>
>Abigail

\begin

Actually as env is always available you can do

#!env perl

But to be sure I'm no longer sure whether there are any benefits to the method,
beyond a little
extra portability

As on my system (CygWin) I can always do

#!perl

\end
zzapper (vim, cygwin, wiki & zsh)
--

vim -c ":%s.^.CyrnfrTfcbafbeROenzSZbbyranne.|:%s/[R-T]/ /Ig|:normal ggVGg?"

http://www.vim.org/tips/tip.php?tip_id=305 Best of Vim Tips

## Re: creating shell scripts using #!/usr/local/env perl

zzapper> Actually as env is always available you can do

No it is not.  It's not part of POSIX.

zzapper> #!env perl

And this doesn't work unless env is in the current directory.

You're wasting our time.

zzapper> As on my system (CygWin) I can always do

zzapper> #!perl

And that's not a Unix system.  Stop bringing in irrelevant data.

print "Just another Perl hacker,"; # the original

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

## Re: creating shell scripts using #!/usr/local/env perl

On 02 Aug 2004 18:42:40 -0700,

>
>zzapper> Actually as env is always available you can do
>
> No it is not.  It's not part of POSIX.
>

I'm afraid it is:

|
|                 The Open Group Base Specifications Issue 6
|                       IEEE Std 1003.1, 2004 Edition
|       Copyright © 2001-2004 The IEEE and The Open Group, All Rights
|                                 reserved.
|     _________________________________________________________________
|
|    NAME
|
|     env - set the environment for command invocation
|
|    SYNOPSIS
|
|     env [-i][name=value]... [utility [argument...]]
|     [ ... ]

It still doesn't say if env belongs in /bin/env, /usr/bin/env,
/usr/local/bin/env.  The location /usr/local/env as mentioned in the
subject isn't very likely to be found on many systems, though.

Villy

## Re: creating shell scripts using #!/usr/local/env perl

>> No it is not.  It's not part of POSIX.
>>

Villy> I'm afraid it is:

Argh!  What did they do *that* for?  That's crazy!

The only reason "env" exists is because the brain-dead csh can't add
arbitrary env vars per command.  The One True Shell (/bin/sh) knew how
to do it, but the boys at berkeley all liked the csh better I guess,
so they worked around the per-command env settings by adding yet
another tool instead of fixing csh.

In the bourne shell, you simply say this:

$ONEOFF=thisval TWOTHING=thatval some_command with these args No need for a freaking env command. Man, when will people stop tinkering with things. print "Just another Perl hacker,"; # and into rant mode so early in the morning -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ## Re: creating shell scripts using #!/usr/local/env perl On 03 Aug 2004, merlyn@stonehenge.com wrote: > The only reason "env" exists is because the brain-dead csh can't add > arbitrary env vars per command. The One True Shell (/bin/sh) knew how > to do it, but the boys at berkeley all liked the csh better I guess, > so they worked around the per-command env settings by adding yet > another tool instead of fixing csh. > > In the bourne shell, you simply say this: > >$ ONEOFF=thisval TWOTHING=thatval some_command with these args
>
> No need for a freaking env command.

It should be noted that env will work in ANY shell, not just csh.
That makes it a more useful tool than you imply.

Ted

## Re: creating shell scripts using #!/usr/local/env perl

Ted> It should be noted that env will work in ANY shell, not just csh.
Ted> That makes it a more useful tool than you imply.

Well, I think I'm trying to imply that it's not needed in *decent*
shells.  It's needed only in *broken* shells.  Hence, merely
a workaround for csh's dain-bramage (one of many).

print "Just another Perl hacker,"; # the original

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

## Re: creating shell scripts using #!/usr/local/env perl

On 04 Aug 2004, merlyn@stonehenge.com wrote:

>
> Ted> It should be noted that env will work in ANY shell, not just csh.
> Ted> That makes it a more useful tool than you imply.
>
> Well, I think I'm trying to imply that it's not needed in *decent*
> shells.  It's needed only in *broken* shells.  Hence, merely
> a workaround for csh's dain-bramage (one of many).

env - has already been pointed out.  I also, as a matter of
personal choice, like a tool that works in ANY shell, and the env
syntax is clearer to me than prepending environment vars to the
command line.  TMTOWTDI.

Some of us use and like tcsh, as an example of 'any' shell as
mentioned above.  I would not consider tcsh broken, and neither would
most people.

Sorry for the off-topic posts.

Ted

## Re: creating shell scripts using #!/usr/local/env perl

Ted> Some of us use and like tcsh, as an example of 'any' shell as
Ted> mentioned above.  I would not consider tcsh broken, and neither would
Ted> most people.

<http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

## Re: creating shell scripts using #!/usr/local/env perl

merlyn@stonehenge.com (Randal L. Schwartz) said:
>Argh!  What did they do *that* for?  That's crazy!
>
>The only reason "env" exists is because the brain-dead csh can't add
>arbitrary env vars per command.

Hmm.. rather hard to duplicate functionality of  'env - command', I'd
say. Not that I've ever used that form, but still - that would be one
use of env even for Bourne shells.
--
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

## Re: creating shell scripts using #!/usr/local/env perl

>
> Actually as env is always available you can do
>
> #!env perl
>
> But to be sure I'm no longer sure whether there are any benefits to the
method, beyond a little
> extra portability

If you define portability as "works on at least one  system". But not on those
uncommon systems like linux and solaris - no one uses them anyway...

--
Sam Holden

## Re: creating shell scripts using #!/usr/local/env perl

wrote:

>I've recently discovered that you call write "perl" Shell scripts using
>the following bang
>
>#!/usr/local/env perl

I strongly suppose you do know that this is not strictly perl-related.
of that kind of shebang.

>This is really cute but,I've already discovered one limitation , you cannot
call such a script via
>the dot method (seems to ignore the bang)

Please pardon my ignorance, but... what is the "dot method"?

Honestly, I'd be curious to know what it is, since the way you talk
about it suggests that is something that should be popular enough to
be widely known...

Re "#!/usr/local/env perl" I'd say on google looking for the
discussions briefly hinted to above. Re "#!/usr/local/env", which may
be relevant enough re perl, I'd say "man env"...

Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"

## Re: creating shell scripts using #!/usr/local/env perl

> wrote:

[...]

> >This is really cute but,I've already discovered one limitation , you
> cannot call such a script via
> >the dot method (seems to ignore the bang)
>
> Please pardon my ignorance, but... what is the "dot method"?

Unix shells have a built-in command to read a file and interpret the
content as commands in the currently running shell.  With Bourne-like
shells, this command is ".", so the process may be called the "dot
method".  (With csh-like shells, the command is "source".)

The interpreting shell is fixed with these commands, it is the
shell that is already running.  There is no room for switching
to another, and so there is no way these scripts could honor the
shebang line.

> Honestly, I'd be curious to know what it is, since the way you talk
> about it suggests that is something that should be popular enough to
> be widely known...

It is popular and widely known among shell programmers.  It has
nothing to do with Perl.

Anno

## Re: creating shell scripts using #!/usr/local/env perl

AS> Unix shells have a built-in command to read a file and interpret the
AS> content as commands in the currently running shell.  With Bourne-like
AS> shells, this command is ".", so the process may be called the "dot
AS> method".  (With csh-like shells, the command is "source".)

and perl spells it 'do \$file' :)

uri

## Re: creating shell scripts using #!/usr/local/env perl

On 3 Aug 2004 08:13:27 GMT, anno4000@lublin.zrz.tu-berlin.de (Anno
Siegel) wrote:

>> >This is really cute but,I've already discovered one limitation , you
>> >cannot call such a script via
^^^^
^^^^

>> >the dot method (seems to ignore the bang)
>>
>> Please pardon my ignorance, but... what is the "dot method"?
>
>Unix shells have a built-in command to read a file and interpret the
>content as commands in the currently running shell.  With Bourne-like

Oh, but then I *do* know what it is. Only I was misleaded by the
expression used above by the OP, since as I have always understood it,
the "dot method" is just... er, well, to repeat exactly you words, "to
read a file and interpret the content as commands in the currently
running shell", so that it shouldn't come as a surprise that "shebang
line isn't honoured", but is *should* come as a surprise that it

>The interpreting shell is fixed with these commands, it is the
>shell that is already running.  There is no room for switching
>to another, and so there is no way these scripts could honor the
>shebang line.

But then again, if I have ever understood the whole thing correctly
there's no way for the currently running shell to understand that it
is a perl script at all. And this is why I couldn't understand what it
was abouty, since I wouldn't reagard the "dot method" as a means to
"call a (perl - or whatever!) script".

>> Honestly, I'd be curious to know what it is, since the way you talk
>> about it suggests that is something that should be popular enough to
>> be widely known...
>
>It is popular and widely known among shell programmers.  It has
>nothing to do with Perl.

FWIW my distro init scripts are (reasonably enough!) full of such
constructs...

Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"

## Re: creating shell scripts using #!/usr/local/env perl

> On 3 Aug 2004 08:13:27 GMT, anno4000@lublin.zrz.tu-berlin.de (Anno
> Siegel) wrote:

[...]

> >> Please pardon my ignorance, but... what is the "dot method"?

[...]

> >The interpreting shell is fixed with these commands, it is the
> >shell that is already running.  There is no room for switching
> >to another, and so there is no way these scripts could honor the
> >shebang line.
>
> But then again, if I have ever understood the whole thing correctly
> there's no way for the currently running shell to understand that it
> is a perl script at all. And this is why I couldn't understand what it
> was abouty, since I wouldn't reagard the "dot method" as a means to
> "call a (perl - or whatever!) script".

Quite so.  The content of a "dot file" must be interpretable by the
current shell.  No other language will do.

Anno

## Re: creating shell scripts using #!/usr/local/env perl

On Mon, 02 Aug 2004, david@tvisnospam.co.uk wrote:

> I've recently discovered that you call write "perl" Shell scripts using
> the following bang
>
> #!/usr/local/env perl
>
> This is really cute but,I've already discovered one limitation , you
> cannot call such a script via the dot method (seems to ignore the
> bang)

The env program itself may pick up the wrong Perl.  Consider:

PATH /usr/bin
env perl => /usr/bin/perl
PATH /usr/local/bin
env perl => /usr/local/bin/perl

So an incorrect path may cause the wrong or no version of Perl to be
picked up, depending on the USER's settings.

As others pointed out, you may as well specify the path yourself.
This is still not possible sometimes across various machines, so you
can:

a) set up a templating system, e.g. autoconf, which will rewrite the
script with the correct shebang line when it's installed;

b) write a shell wrapper that chooses the right version of Perl based
on the output of uname, for instance.

Ted