[32988] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4264 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 11 05:17:16 2014

Date: Mon, 11 Aug 2014 02:17:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Mon, 11 Aug 2014     Volume: 11 Number: 4264

Today's topics:
    Re: How can I point to different Perl compilers based o <rweikusat@mobileactivedefense.com>
    Re: How can I point to different Perl compilers based o <richardn@nospam.com>
    Re: How can I point to different Perl compilers based o <richardn@nospam.com>
    Re: How can I point to different Perl compilers based o <richardn@nospam.com>
    Re: How can I point to different Perl compilers based o <richardn@nospam.com>
    Re: How can I point to different Perl compilers based o <kst-u@mib.org>
    Re: How can I point to different Perl compilers based o <kst-u@mib.org>
    Re: How can I point to different Perl compilers based o <hjp-usenet3@hjp.at>
    Re: How can I point to different Perl compilers based o <rweikusat@mobileactivedefense.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sat, 09 Aug 2014 18:11:34 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <87d2c9vb95.fsf@sable.mobileactivedefense.com>

Keith Thompson <kst-u@mib.org> writes:
> Richard Nicholas <richardn@nospam.com> writes:
>> In article <87oavv9ech.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com 

[...]

>>> 	- use a shell script as interpreter which does an exec of the
>>>           actual perl binary based on a suitable test, eg, uname
>
> If you mean specifying the path to a shell script on the #! line, not
> all systems support this; some require the interpreter to be a binary
> executable, not a script to be executed via another interpreter.
> (Linux seems to have added the capability some time around version
> 3 of the kernel.)

According to

http://www.in-ulm.de/~mascheck/various/shebang/

only Linux, Minix, Hurd and Cygwin do.



------------------------------

Date: Sat, 9 Aug 2014 15:18:36 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e503e192c2c464d9897ec@news.eternal-september.org>

In article <slrnlubfmt.7r8.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
> 
> On 2014-08-09 02:48, Richard Nicholas <richardn@nospam.com> wrote:
> > In article <ls3nc6$ug4$1@news.ntua.gr>, gravitalsun@hotmail.foo says...
> >> On 8/8/2014 5:26 µµ, Richard Nicholas wrote:
> >> > I guess what I am looking for is for the shell script to be able
> >> > tell the one Perl script where to go find its Perl by passing via
> >> > an environment variable or some other way.  Any way to do that?
> >> 
> >> #!/usr/bin/env perl
> >> print 'hello wor ld'
> >
> > If this solves my problem, I don't understand it.  Is env a script
> > like in Rainer's solution?
> 
> Sort of. It's a standard unix utility which is normally used to invoke
> another command with an altered environment. Here we ignore its ability
> to change the environment and just take advantage of the fact that it
> can invoke a command from the PATH, and that - being a standard unix
> utility - env itself is (almost?) always in /usr/bin.
> 
> Personally, I don't like this solution much: Like Rainer's script it
> invokes another program which then searches and invokes a perl
> interpreter. But the real killer for me is that searches the PATH: This
> can lead to mysterious failures if several versions of perl are
> installed and depending on context (different users, cron jobs, ...) one
> or the other may be first in the PATH. But I have to admit that it is
> very simple and it works for most people.
> 
>         hp

And so I would instruct the users of my program to make sure that 64-bit Perl is the first 
"perl" found in their path?  Not transparent but it may be a doable solution...

Richard Nicholas


------------------------------

Date: Sat, 9 Aug 2014 15:22:17 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e503ef8609fcf3f9897ed@news.eternal-september.org>

In article <slrnlubenu.7r8.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
> 
> On 2014-08-08 14:26, Richard Nicholas <richardn@nospam.com> wrote:
> > I have a problem I hope you can help with.  In a perfect world, my
> > script starts with:
> >
> > #!/usr/bin/perl
> >
> > and each system grabs its own installed perl and runs the script.
> >
> > However, this script requires 64-bit Perl and not all /usr/bin/perl
> > are 64-bit.  There are many systems across many sites so its not an
> > option to make sure all /usr/bin/perl points to 64-bit Perl.
> 
> Of course installing perl code on "many systems across many sites" has
> always been a problem for Perl programmers distributing their code via
> CPAN. And so it is not surprising that a standard solution exists. Well,
> actually several standard solutions, according to Perl's motto
> TIMTOWTDI. I'm just mentioning the oldest and most simple here:
> 
> If you have a script named "hello", create a second script called
> Makefile.PL with this content:
> 
>     use ExtUtils::MakeMaker;
>     WriteMakefile(
>         EXE_FILES => [ "hello" ]
>     );
> 
> Then invoke it with the perl interpreter you want to use:
> 
>     perl Makefile.PL
> 
> and use the resulting Makefile to install your script:
> 
>     make install
> 
> The installed script will have the correct #! line for the perl version
> used to install it.
> 
> (I would have recommended Module::Build because it doesn't need make,
> but I couldn't get it to stop complaining that I wasn't actually
> installing a module)

I may be misunderstanding but I don't think this kind of solution is what I am looking for.  
It sounds like what I would want if each of my users were installing their own version of my 
program.  But the case here is the program just exists in one spot and all the systems access 
it over the networked file system.  And the program itself can't just point to the "correct" 
Perl because which one is correct depends on the OS of the user.

Richard Nicholas


------------------------------

Date: Sat, 9 Aug 2014 15:26:18 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e503fe1bee9a4669897ee@news.eternal-september.org>

In article <066548db-7b5a-43fe-b764-d2dfcb2d82c1@googlegroups.com>, sharma__r@hotmail.com 
says...
> I propose a different approach to your problem, which uses the
> env variable OSTYPE to determine the OS.
> 
> And in case the env OSTYPE is not found,
> then the "uname" command would do.
> 
> eval '
> case ${OSTYPE-} in
> "cygwin") perl="/usr/bin/cygwin64/perl";;
> "linux") perl="/usr/bin/linux64/perl";;
> ""|*) echo >&2 "Unknown OS:[${OSTYPE-}]"; exit 1;;
> esac
> exec "$perl" -w -S -- "$0" ${1+"$@"}
> '
> if 0;
> 
> ## your perl code follows underneath...
> print "Hello, world!\n";
> ....
> 
> Note: All this is in one file where your perl code resides.
> 

Pretty clever - a one script solution!  Thanks.

Richard Nicholas


------------------------------

Date: Sat, 9 Aug 2014 15:37:08 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e50426d68f0da3d9897ef@news.eternal-september.org>

In article <7khbu95s5urlg46j390cteml203okf4nqb@4ax.com>, carl.inglis@gmail.com says...
> 
> On Fri, 8 Aug 2014 22:19:39 -0500, Richard Nicholas
> <richardn@nospam.com> wrote:
> 
> [much big snip]
> 
> This link might help explain what's actually happening with the #!
> line:
> 
> http://en.wikipedia.org/wiki/Shebang_%28Unix%29
> 
> Hope that helps.
> 
> Regards,
> 
> Carl

Carl, thanks.  Now I understand why when scr.pl starts with

#!/usr/bin/perl1

I can run the program with perl2 by calling

perl2 scr.pl

If I just run scr.pl by itself, the shell calls perl1 for me and passes it scr.pl as the 
parameter.  But if I run perl2 scr.pl, perl2 runs the script.  Both perl1 and perl2 ignore 
the #! line because its a comment to Perl.  That is the main part I was missing.  The #! is 
directed to the shell, not to Perl - its ignored by Perl.

Richard Nicholas


------------------------------

Date: Sat, 09 Aug 2014 19:20:18 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <ln38d5qe59.fsf@nuthaus.mib.org>

Richard Nicholas <richardn@nospam.com> writes:
> In article <ls3nc6$ug4$1@news.ntua.gr>, gravitalsun@hotmail.foo says...
>> On 8/8/2014 5:26 µµ, Richard Nicholas wrote:
>> > I guess what I am looking for is for the shell script to be able
>> > tell the one Perl script where to go find its Perl by passing via
>> > an environment variable or some other way.  Any way to do that?
>> >
>> > Richard Nicholas
>> >
>> 
>> 
>> #!/usr/bin/env perl
>> print 'hello wor ld'
>
> If this solves my problem, I don't understand it.  Is env a script
> like in Rainer's solution?

The advantage is that it uses the first "perl" executable found in the
user's $PATH.

The disadvantage is that it uses the first "perl" executable found in
the user's $PATH.

More discussion here:
    http://unix.stackexchange.com/q/29608/10454
    http://unix.stackexchange.com/a/29620/10454

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"


------------------------------

Date: Sat, 09 Aug 2014 19:23:06 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <lny4uxozg5.fsf@nuthaus.mib.org>

Richard Nicholas <richardn@nospam.com> writes:
[...]
> Carl, thanks.  Now I understand why when scr.pl starts with
>
> #!/usr/bin/perl1
>
> I can run the program with perl2 by calling
>
> perl2 scr.pl
>
> If I just run scr.pl by itself, the shell calls perl1 for me and
> passes it scr.pl as the parameter.  But if I run perl2 scr.pl, perl2
> runs the script.  Both perl1 and perl2 ignore the #! line because its
> a comment to Perl.  That is the main part I was missing.  The #! is
> directed to the shell, not to Perl - its ignored by Perl.

The #! is actually handled by the OS kernel, not by the shell.  The
distinction means that it works even if a program is invoked by another
program (say, using fork() and exec()) rather than by a shell.

A script with a #! line acts almost entirely like a binary executable; a
user doesn't have to care how it's executed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"


------------------------------

Date: Sun, 10 Aug 2014 10:57:03 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <slrnluecv2.ome.hjp-usenet3@hrunkner.hjp.at>

On 2014-08-09 20:22, Richard Nicholas <richardn@nospam.com> wrote:
> In article <slrnlubenu.7r8.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
>> On 2014-08-08 14:26, Richard Nicholas <richardn@nospam.com> wrote:
>> > I have a problem I hope you can help with.  In a perfect world, my
>> > script starts with:
>> >
>> > #!/usr/bin/perl
>> >
>> > and each system grabs its own installed perl and runs the script.
>> >
>> > However, this script requires 64-bit Perl and not all /usr/bin/perl
>> > are 64-bit.  There are many systems across many sites so its not an
>> > option to make sure all /usr/bin/perl points to 64-bit Perl.
>> 
>> Of course installing perl code on "many systems across many sites" has
>> always been a problem for Perl programmers distributing their code via
>> CPAN. And so it is not surprising that a standard solution exists. Well,
>> actually several standard solutions, according to Perl's motto
>> TIMTOWTDI. I'm just mentioning the oldest and most simple here:
[... using MakeMaker ...]

> I may be misunderstanding but I don't think this kind of solution is
> what I am looking for.  It sounds like what I would want if each of my
> users were installing their own version of my program.  But the case
> here is the program just exists in one spot and all the systems access
> it over the networked file system.

Ok, you didn't say that. When you wrote about "many systems across many
sites" I assumed you wanted to install your script on each of them, not
install it in a central location and access it through a network file
system.

> And the program itself can't just point to the "correct" Perl because
> which one is correct depends on the OS of the user.

You don't need to install a version for every user, but for every
machine, or at least machine type. Think of it as a binary. Just like
you would have to have a different binary for Windows, OS X, Linux/x86,
Linux/x64, you want a different version for each perl installation. If
you have two groups of machines, one if which has a suitable perl
interpreter in /usr/bin and the other in
/opt/perl-5.18.2-x86_64-linux-thread-multi/bin, you can share one script
within each group. I'm not sure it's worthwhile, though. Just
distributing the script to all systems seems simpler to me.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Sun, 10 Aug 2014 17:45:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <877g2gb8f3.fsf@sable.mobileactivedefense.com>

sharma__r@hotmail.com writes:

[select a perl based on OS]

> I propose a different approach to your problem, which uses the
> env variable OSTYPE to determine the OS.
>
> And in case the env OSTYPE is not found,
> then the "uname" command would do.
>
> eval '
> case ${OSTYPE-} in
> "cygwin") perl="/usr/bin/cygwin64/perl";;
> "linux") perl="/usr/bin/linux64/perl";;
> ""|*) echo >&2 "Unknown OS:[${OSTYPE-}]"; exit 1;;
> esac
> exec "$perl" -w -S -- "$0" ${1+"$@"}
> '
> if 0;
>
> ## your perl code follows underneath...
> print "Hello, world!\n";
> ....

OSTYPE is not an environment variable, it's a 'special variable'
supported by bash. Assuming I save this to a file, make it executable
and try to run it from an interactive bash, the result is

[rw@sable]/tmp#./a 
Unknown OS:[linux-gnu]

Doing the with dash yields

$ ./a
Unknown OS:[]

because that doesn't know anything about OSTYPE. Considering this, the
${1+"$@} is useless voodoo, cf

http://www.in-ulm.de/~mascheck/various/bourne_args/


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 4264
***************************************


home help back first fref pref prev next nref lref last post