[32987] in Perl-Users-Digest
Perl-Users Digest, Issue: 4263 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 9 05:17:18 2014
Date: Sat, 9 Aug 2014 02:17:06 -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 Sat, 9 Aug 2014 Volume: 11 Number: 4263
Today's topics:
Re: How can I point to different Perl compilers based o <news@todbe.com>
Re: How can I point to different Perl compilers based o <derykus@gmail.com>
Re: How can I point to different Perl compilers based o <gregor+usenet-0601@comodo.priv.at>
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 <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 <derykus@gmail.com>
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 <hjp-usenet3@hjp.at>
Re: How can I point to different Perl compilers based o <carl.inglis@gmail.com>
Re: How can I point to different Perl compilers based o sharma__r@hotmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 08 Aug 2014 18:32:45 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <ls3tnp$72b$1@dont-email.me>
On 8/8/2014 17:37, Keith Thompson wrote:
> "$Bill" <news@todbe.com> writes:
>> On 8/8/2014 13:30, Richard Nicholas wrote:
>>> A related question. By using perl -V, I can find out the value of
>>> ivsize. Can I grab the value of ivsize from inside my Perl program?
>>
>> Sure. This works on Windoze, you'll have to check on NIX.
>>
>> #!perl --
>>
>> use strict;
>> use warnings;
>>
>> my $ver = `perl -V`;
>> if ($ver =~ /ivsize=(\d+)/is) {
>> print "ivsize = $1\n";
>> } else {
>> print "ivsize = unknown\n";
>> }
>>
>> __END__
>
> That gives you the value of ivsize for the first "perl" executable in
> your $PATH / %PATH%, which may or may not be the perl that's running
> your script.
Which is the Perl you are running under on Doze. Easy enough to
add a path to check other Perl versions.
------------------------------
Date: Fri, 08 Aug 2014 18:58:51 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <ls3v9h$ir$1@speranza.aioe.org>
On 8/8/2014 6:32 PM, $Bill wrote:
> On 8/8/2014 17:37, Keith Thompson wrote:
>> "$Bill" <news@todbe.com> writes:
>>> On 8/8/2014 13:30, Richard Nicholas wrote:
>>>> A related question. By using perl -V, I can find out the value of
>>>> ivsize. Can I grab the value of ivsize from inside my Perl program?
>>>
>>> Sure. This works on Windoze, you'll have to check on NIX.
>>>
>>> #!perl --
>>>
>>> use strict;
>>> use warnings;
>>>
>>> my $ver = `perl -V`;
>>> if ($ver =~ /ivsize=(\d+)/is) {
>>> print "ivsize = $1\n";
>>> } else {
>>> print "ivsize = unknown\n";
>>> }
>>>
>>> __END__
>>
>> That gives you the value of ivsize for the first "perl" executable in
>> your $PATH / %PATH%, which may or may not be the perl that's running
>> your script.
>
> Which is the Perl you are running under on Doze. Easy enough to
> add a path to check other Perl versions.
>
Config can be useful here:
use Config; say "$Config{osname} : $Config{perlpath} : $Config{ivsize}";
--
Charles DeRykus
------------------------------
Date: Sat, 9 Aug 2014 04:12:35 +0200
From: gregor herrmann <gregor+usenet-0601@comodo.priv.at>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <klcgbbxfhr.ln2@news.comodo.priv.at>
On Fri, 8 Aug 2014 15:30:26 -0500, Richard Nicholas wrote:
> A related question. By using perl -V, I can find out the value of ivsize. Can I grab the
> value of ivsize from inside my Perl program?
use Config;
print $Config{ivsize};
% perl -MConfig -E 'say $Config{ivsize};'
8
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Derek Patton: Apes in the Rotunda
------------------------------
Date: Fri, 8 Aug 2014 21:41:29 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f463a40f72e6e9897e5@news.eternal-september.org>
In article <klcgbbxfhr.ln2@news.comodo.priv.at>, gregor+usenet-0601@comodo.priv.at says...
> use Config;
> print $Config{ivsize};
Great, thanks! It works.
Richard Nicholas
------------------------------
Date: Fri, 8 Aug 2014 21:45:00 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f472541058aea9897e6@news.eternal-september.org>
In article <ls3tnp$72b$1@dont-email.me>, news@todbe.com says...
>
> On 8/8/2014 17:37, Keith Thompson wrote:
> > "$Bill" <news@todbe.com> writes:
> >> On 8/8/2014 13:30, Richard Nicholas wrote:
> >>> A related question. By using perl -V, I can find out the value of
> >>> ivsize. Can I grab the value of ivsize from inside my Perl program?
> >>
> >> Sure. This works on Windoze, you'll have to check on NIX.
> >>
> >> #!perl --
> >>
> >> use strict;
> >> use warnings;
> >>
> >> my $ver = `perl -V`;
> >> if ($ver =~ /ivsize=(\d+)/is) {
> >> print "ivsize = $1\n";
> >> } else {
> >> print "ivsize = unknown\n";
> >> }
> >>
> >> __END__
> >
> > That gives you the value of ivsize for the first "perl" executable in
> > your $PATH / %PATH%, which may or may not be the perl that's running
> > your script.
>
> Which is the Perl you are running under on Doze. Easy enough to
> add a path to check other Perl versions.
Well, what we've been discussing is calling the same script with different Perl executables
so the script itself might want to know something about the executable that is running it.
Richard Nicholas
------------------------------
Date: Fri, 8 Aug 2014 21:45:50 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f47578d2fb9159897e7@news.eternal-september.org>
In article <ls3v9h$ir$1@speranza.aioe.org>, derykus@gmail.com says...
>
> On 8/8/2014 6:32 PM, $Bill wrote:
> > On 8/8/2014 17:37, Keith Thompson wrote:
> >> "$Bill" <news@todbe.com> writes:
> >>> On 8/8/2014 13:30, Richard Nicholas wrote:
> >>>> A related question. By using perl -V, I can find out the value of
> >>>> ivsize. Can I grab the value of ivsize from inside my Perl program?
> >>>
> >>> Sure. This works on Windoze, you'll have to check on NIX.
> >>>
> >>> #!perl --
> >>>
> >>> use strict;
> >>> use warnings;
> >>>
> >>> my $ver = `perl -V`;
> >>> if ($ver =~ /ivsize=(\d+)/is) {
> >>> print "ivsize = $1\n";
> >>> } else {
> >>> print "ivsize = unknown\n";
> >>> }
> >>>
> >>> __END__
> >>
> >> That gives you the value of ivsize for the first "perl" executable in
> >> your $PATH / %PATH%, which may or may not be the perl that's running
> >> your script.
> >
> > Which is the Perl you are running under on Doze. Easy enough to
> > add a path to check other Perl versions.
> >
>
> Config can be useful here:
>
> use Config; say "$Config{osname} : $Config{perlpath} : $Config{ivsize}";
Great, thanks! It works.
Richard Nicholas
------------------------------
Date: Fri, 8 Aug 2014 21:48:51 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f480cd74096ed9897e8@news.eternal-september.org>
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?
Richard Nicholas
------------------------------
Date: Fri, 8 Aug 2014 22:03:04 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f4b4c44bab3379897e9@news.eternal-september.org>
In article <ls3v9h$ir$1@speranza.aioe.org>, derykus@gmail.com says...
>
> On 8/8/2014 6:32 PM, $Bill wrote:
> > On 8/8/2014 17:37, Keith Thompson wrote:
> >> "$Bill" <news@todbe.com> writes:
> >>> On 8/8/2014 13:30, Richard Nicholas wrote:
> >>>> A related question. By using perl -V, I can find out the value of
> >>>> ivsize. Can I grab the value of ivsize from inside my Perl program?
> >>>
> >>> Sure. This works on Windoze, you'll have to check on NIX.
> >>>
> >>> #!perl --
> >>>
> >>> use strict;
> >>> use warnings;
> >>>
> >>> my $ver = `perl -V`;
> >>> if ($ver =~ /ivsize=(\d+)/is) {
> >>> print "ivsize = $1\n";
> >>> } else {
> >>> print "ivsize = unknown\n";
> >>> }
> >>>
> >>> __END__
> >>
> >> That gives you the value of ivsize for the first "perl" executable in
> >> your $PATH / %PATH%, which may or may not be the perl that's running
> >> your script.
> >
> > Which is the Perl you are running under on Doze. Easy enough to
> > add a path to check other Perl versions.
> >
>
> Config can be useful here:
>
> use Config; say "$Config{osname} : $Config{perlpath} : $Config{ivsize}";
Actually, I just found out that while this does work for ivsize, it does NOT work for
perlpath. I.e. when I call the script with different Perl executables, I get the right
ivsize for the executable I am using but I don't get that path to that executable; it always
gives the path to the default Perl.
Richard Nicholas
------------------------------
Date: Fri, 8 Aug 2014 22:06:55 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f4c4fcfa329b89897ea@news.eternal-september.org>
In article <lnk36iqysi.fsf@nuthaus.mib.org>, kst-u@mib.org says...
> Richard Nicholas <richardn@nospam.com> writes:
> > In article <87oavv9ech.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> > says...
> >> The two obvious ideas would be
> >>
> >> - require a 'standardized' name for a suitable Perl, eg
> >> /usr/bin/perl64
> >
> > This one I can't do because I can't control what is in /usr/bin for
> > all the systems.
>
> Does that mean you also can't control what's in, say, /usr/local/bin?
> If there's any path you can control on all the relevant systems, it
> doesn't matter what's in /usr/bin.
No, I can't control any path on all the local systems, and if I use a path on the network
that they all have access to, I won't be able to choose different executables for different
OS'es without using one of the other solutions that have been talked about.
Richard Nicholas
------------------------------
Date: Fri, 8 Aug 2014 22:19:39 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4f4f2bee06a4b19897eb@news.eternal-september.org>
In article <877g2ifya4.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
>
> Richard Nicholas <richardn@nospam.com> writes:
> > In article <8738d61z2r.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> > says...
> >>
> >> Richard Nicholas <richardn@nospam.com> writes:
> >> > In article <87a97elrh1.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> >> > says...
> >>
> >> [...]
> >>
> >> >> The idea was to use a script selecting the perl interpreter to run as
> >> >> interpreter for the actual perl script. Unfortunately, this requires
> >> >> some contortions as perl interprets the #!-line itself. Example which
> >> >> works: Assuming that /tmp/script is a script containing the following
> >> >> code:
> >> >>
> >> >> ---------
> >> >> #!/bin/sh
> >> >>
> >> >> echo "I'm the intermediate!"
> >> >>
> >> >> shift
> >> >> exec perl "$@"
> >> >> ---------
> >> >>
> >> >> and /tmp/a.pl is an excutable file containing
> >> >>
> >> >> ---------
> >> >> #!/tmp/script perl
> >> >> print("This is perl\n");
> >> >> ---------
> >> >>
> >> >> invoking a.pl (./a.pl) will run the script script for passing the
> >> >> 'actual' script to perl.
> >> >
> >> > Wow, thanks but this seems very convoluted.
> >>
> >> You should try to get your head around the idea that #! is just a way to
> >> tell the kernel that it should automatically run the file named after it
> >> with the 'script path' as first argument (slight simplification) and any
> >> other arguments appened in order to run 'the script' ...
> >
> > But try as I might, I don't follow your example. What is this doing?
> >
> > shift
> > exec perl "$@"
>
> perl (the program) processes the #!-line, see DESCRIPTION of
> perlrun(1). In case it doesn't find the string 'perl' on it, it emulates
> 'standard #!' because someone apparently couldn't think of another
> reason why the #! of a Perl script wouldn't be 'something named perl',
> cf
>
> If the "#!" line does not contain the word "perl", the program
> named after the "#!" is executed instead of the Perl
> interpreter. This is slightly bizarre, but it
> helps people on machines that don't do "#!", because they can
> tell a program that their SHELL is /usr/bin/perl, and Perl will
> then dispatch the program to the correct interpreter for them.
>
> Because of this, there was an artificial 'perl' on the #!-line of the
> intermediate interpreter,
>
> #!/tmp/script perl
>
> this implies that $1 (the first argument) will be 'perl' and since
> that's not useful, the
>
> shift
>
> gets rid of that.
>
> exec perl "$@"
>
> just execute whatever perl is found in the PATH and passes all arguments
> passed to the intermediate interpreter script itself to it.
>
> It is also possible to use a suitable name for the interpreters, eg,
> /usr/local/bin/my_perl,
>
> -----------
> #!/bin/sh
> #
>
> echo "Intermediate" # could do anything here
>
> exec perl "$@"
> -----------
>
> works, to.
>
> >> > I still think the more straightforward approach
> >> > is to do what I thought you were originally proposing which is for the user to call "script"
> >> > which figures out OS and will then run my Perl "script.pl" using the correct Perl compiler
> >> > for that OS.
> >>
> >> ... because whoever uses 'the script' probably doesn't care one iota
> >> about the mechanics necessary to run it: If running your script requires
> >> some 'special preprocessing' before it can actually be executed, the
> >> sensible way to accomplish that is to use an interpreter which does in
> >> the a user-transparent way, not
> >>
> >> callme1 -a callme2 -y ... callme5321 -aa
> >> /work/around/code/author/by/hand
> >
> > I'm not sure if all that is supposed to represent what I was proposing
>
> Not really. That was something I thought of but you clearly didn't.
>
> > but what I was
> > proposing (which is the only way I understand at the moment) is the following. Let's say my
> > Perl script is script.pl. I would create a script called "script" which is what the user
> > calls and is all the user has to know about. "script" is basically this in pseudo-code:
> >
> > if (OS == AIX) {
> > /path/to/aix/perl64 script.pl
> > }
> >
> > if (OS == LINUX) {
> > /path/to/linux/perl64 script.pl
> > }
> >
> > Its a little more just because whatever parameters are passed to script, I have to pass to
> > script.pl but that's the basic idea.
>
> The trouble with this is that you'll need to create an individual
> wrapper script for every Perl script you want to execute in this
> way. The #!-mechanism itself can be used to avoid that. Assuming an
> executable file named /usr/local/bin/something exists and it starts with
>
> #!/usr/local/bin/something-else
>
> and the kernel supports #!, it will end up doing an equivalent of
>
> execl("/usr/local/bin/something-else", "/usr/local/bin/something", "/usr/local/bin/something", (void *)0)
>
> when a user tries to run something (assuming its in the path).
>
> Instead of creating a wrapper script for this particular perl-script,
> you can write some kind of 'interpreter program' (using whatever
> programming language seems convenient) which contains the logic
> necessary for locating the correct perl and then invokes that with all
> arguments passed to the interpreter program itself. The path to this
> interpreter-program can then be used instead of /usr/bin/perl on the
> #!-line of all Perl-scripts which need to be run in this way and
> everything will 'magically' work (minus the perl-on-shebang-line issue
> mentioned above).
Ok, I see what you are trying to accomplish here. I appreciate it but I would have to spend
some more time figuring it out. Its a bit advanced for my purposes. I agree if a lot of
scripts need to be run this way, a more general solution would be good but this is the first
one that I've done where its been important to make sure I was grabbing 64-bit Perl so this
issue is not likely to come up enough to warrant a complicated solution yet. Thanks again -
you still inspired the solution I am going with.
Richard Nicholas
------------------------------
Date: Fri, 08 Aug 2014 23:00:34 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <ls4deo$or8$1@speranza.aioe.org>
On 8/8/2014 8:03 PM, Richard Nicholas wrote:
> In article <ls3v9h$ir$1@speranza.aioe.org>, derykus@gmail.com says...
>>
>> On 8/8/2014 6:32 PM, $Bill wrote:
>>> On 8/8/2014 17:37, Keith Thompson wrote:
>>>> "$Bill" <news@todbe.com> writes:
>>>>> On 8/8/2014 13:30, Richard Nicholas wrote:
>>>>>> A related question. By using perl -V, I can find out the value of
>>>>>> ivsize. Can I grab the value of ivsize from inside my Perl program?
>>>>>
>>>>> Sure. This works on Windoze, you'll have to check on NIX.
>>>>>
>>>>> #!perl --
>>>>>
>>>>> use strict;
>>>>> use warnings;
>>>>>
>>>>> my $ver = `perl -V`;
>>>>> if ($ver =~ /ivsize=(\d+)/is) {
>>>>> print "ivsize = $1\n";
>>>>> } else {
>>>>> print "ivsize = unknown\n";
>>>>> }
>>>>>
>>>>> __END__
>>>>
>>>> That gives you the value of ivsize for the first "perl" executable in
>>>> your $PATH / %PATH%, which may or may not be the perl that's running
>>>> your script.
>>>
>>> Which is the Perl you are running under on Doze. Easy enough to
>>> add a path to check other Perl versions.
>>>
>>
>> Config can be useful here:
>>
>> use Config; say "$Config{osname} : $Config{perlpath} : $Config{ivsize}";
>
> Actually, I just found out that while this does work for ivsize, it does NOT work for
> perlpath. I.e. when I call the script with different Perl executables, I get the right
> ivsize for the executable I am using but I don't get that path to that executable; it always
> gives the path to the default Perl.
>
>
Ah as mentioned, it'll find the first perl in the PATH.
IIUC and I'm not missing something obvious, maybe a hack that uses a
prepended arg ?
e.g. myscript.pl FIND64bit foo bar baz
#!/some/path/to/some/perl
use Config;
use constant AIXPERL64BIN => "/path/to/aix64perlbin";
use constant LINUXPERL64BIN => "/path/to/linux64perlbinI";
if ( $ARGV[0] eq "FIND64bit" ) {
shift @ARGV;
if ( $Config{osname} =~ /aix/i ) {
exec AIXPERL64BIN, $0, @ARGV;
} elsif( $Config{osname} =~ /linux/i ) {
exec LINUXPERL64BIN, $0, @ARGV;
} else {
die "unknown os";
}
}
# rest of script...
--
Charles DeRykus
------------------------------
Date: Sat, 9 Aug 2014 08:09:02 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <slrnlubenu.7r8.hjp-usenet3@hrunkner.hjp.at>
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)
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: Sat, 9 Aug 2014 08:25:33 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <slrnlubfmt.7r8.hjp-usenet3@hrunkner.hjp.at>
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
--
_ | 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: Sat, 09 Aug 2014 07:59:39 +0100
From: Carl Inglis <carl.inglis@gmail.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <7khbu95s5urlg46j390cteml203okf4nqb@4ax.com>
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
------------------------------
Date: Sat, 9 Aug 2014 01:45:58 -0700 (PDT)
From: sharma__r@hotmail.com
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <066548db-7b5a-43fe-b764-d2dfcb2d82c1@googlegroups.com>
On Saturday, 9 August 2014 08:49:39 UTC+5:30, Richard Nicholas wrote:
> In article <877g2ifya4.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
>
> says...
>
> >
>
> > Richard Nicholas <richardn@nospam.com> writes:
>
> > > In article <8738d61z2r.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
>
> > > says...
>
> > >>
>
> > >> Richard Nicholas <richardn@nospam.com> writes:
>
> > >> > In article <87a97elrh1.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
>
> > >> > says...
>
> > >>
>
> > >> [...]
>
> > >>
>
> > >> >> The idea was to use a script selecting the perl interpreter to run as
>
> > >> >> interpreter for the actual perl script. Unfortunately, this requires
>
> > >> >> some contortions as perl interprets the #!-line itself. Example which
>
> > >> >> works: Assuming that /tmp/script is a script containing the following
>
> > >> >> code:
>
> > >> >>
>
> > >> >> ---------
>
> > >> >> #!/bin/sh
>
> > >> >>
>
> > >> >> echo "I'm the intermediate!"
>
> > >> >>
>
> > >> >> shift
>
> > >> >> exec perl "$@"
>
> > >> >> ---------
>
> > >> >>
>
> > >> >> and /tmp/a.pl is an excutable file containing
>
> > >> >>
>
> > >> >> ---------
>
> > >> >> #!/tmp/script perl
>
> > >> >> print("This is perl\n");
>
> > >> >> ---------
>
> > >> >>
>
> > >> >> invoking a.pl (./a.pl) will run the script script for passing the
>
> > >> >> 'actual' script to perl.
>
> > >> >
>
> > >> > Wow, thanks but this seems very convoluted.
>
> > >>
>
> > >> You should try to get your head around the idea that #! is just a way to
>
> > >> tell the kernel that it should automatically run the file named after it
>
> > >> with the 'script path' as first argument (slight simplification) and any
>
> > >> other arguments appened in order to run 'the script' ...
>
> > >
>
> > > But try as I might, I don't follow your example. What is this doing?
>
> > >
>
> > > shift
>
> > > exec perl "$@"
>
> >
>
> > perl (the program) processes the #!-line, see DESCRIPTION of
>
> > perlrun(1). In case it doesn't find the string 'perl' on it, it emulates
>
> > 'standard #!' because someone apparently couldn't think of another
>
> > reason why the #! of a Perl script wouldn't be 'something named perl',
>
> > cf
>
> >
>
> > If the "#!" line does not contain the word "perl", the program
>
> > named after the "#!" is executed instead of the Perl
>
> > interpreter. This is slightly bizarre, but it
>
> > helps people on machines that don't do "#!", because they can
>
> > tell a program that their SHELL is /usr/bin/perl, and Perl will
>
> > then dispatch the program to the correct interpreter for them.
>
> >
>
> > Because of this, there was an artificial 'perl' on the #!-line of the
>
> > intermediate interpreter,
>
> >
>
> > #!/tmp/script perl
>
> >
>
> > this implies that $1 (the first argument) will be 'perl' and since
>
> > that's not useful, the
>
> >
>
> > shift
>
> >
>
> > gets rid of that.
>
> >
>
> > exec perl "$@"
>
> >
>
> > just execute whatever perl is found in the PATH and passes all arguments
>
> > passed to the intermediate interpreter script itself to it.
>
> >
>
> > It is also possible to use a suitable name for the interpreters, eg,
>
> > /usr/local/bin/my_perl,
>
> >
>
> > -----------
>
> > #!/bin/sh
>
> > #
>
> >
>
> > echo "Intermediate" # could do anything here
>
> >
>
> > exec perl "$@"
>
> > -----------
>
> >
>
> > works, to.
>
> >
>
> > >> > I still think the more straightforward approach
>
> > >> > is to do what I thought you were originally proposing which is for the user to call "script"
>
> > >> > which figures out OS and will then run my Perl "script.pl" using the correct Perl compiler
>
> > >> > for that OS.
>
> > >>
>
> > >> ... because whoever uses 'the script' probably doesn't care one iota
>
> > >> about the mechanics necessary to run it: If running your script requires
>
> > >> some 'special preprocessing' before it can actually be executed, the
>
> > >> sensible way to accomplish that is to use an interpreter which does in
>
> > >> the a user-transparent way, not
>
> > >>
>
> > >> callme1 -a callme2 -y ... callme5321 -aa
>
> > >> /work/around/code/author/by/hand
>
> > >
>
> > > I'm not sure if all that is supposed to represent what I was proposing
>
> >
>
> > Not really. That was something I thought of but you clearly didn't.
>
> >
>
> > > but what I was
>
> > > proposing (which is the only way I understand at the moment) is the following. Let's say my
>
> > > Perl script is script.pl. I would create a script called "script" which is what the user
>
> > > calls and is all the user has to know about. "script" is basically this in pseudo-code:
>
> > >
>
> > > if (OS == AIX) {
>
> > > /path/to/aix/perl64 script.pl
>
> > > }
>
> > >
>
> > > if (OS == LINUX) {
>
> > > /path/to/linux/perl64 script.pl
>
> > > }
>
> > >
>
> > > Its a little more just because whatever parameters are passed to script, I have to pass to
>
> > > script.pl but that's the basic idea.
>
> >
>
> > The trouble with this is that you'll need to create an individual
>
> > wrapper script for every Perl script you want to execute in this
>
> > way. The #!-mechanism itself can be used to avoid that. Assuming an
>
> > executable file named /usr/local/bin/something exists and it starts with
>
> >
>
> > #!/usr/local/bin/something-else
>
> >
>
> > and the kernel supports #!, it will end up doing an equivalent of
>
> >
>
> > execl("/usr/local/bin/something-else", "/usr/local/bin/something", "/usr/local/bin/something", (void *)0)
>
> >
>
> > when a user tries to run something (assuming its in the path).
>
> >
>
> > Instead of creating a wrapper script for this particular perl-script,
>
> > you can write some kind of 'interpreter program' (using whatever
>
> > programming language seems convenient) which contains the logic
>
> > necessary for locating the correct perl and then invokes that with all
>
> > arguments passed to the interpreter program itself. The path to this
>
> > interpreter-program can then be used instead of /usr/bin/perl on the
>
> > #!-line of all Perl-scripts which need to be run in this way and
>
> > everything will 'magically' work (minus the perl-on-shebang-line issue
>
> > mentioned above).
>
>
>
> Ok, I see what you are trying to accomplish here. I appreciate it but I would have to spend
>
> some more time figuring it out. Its a bit advanced for my purposes. I agree if a lot of
>
> scripts need to be run this way, a more general solution would be good but this is the first
>
> one that I've done where its been important to make sure I was grabbing 64-bit Perl so this
>
> issue is not likely to come up enough to warrant a complicated solution yet. Thanks again -
>
> you still inspired the solution I am going with.
>
>
>
> Richard Nicholas
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.
HTH
-Rakesh
------------------------------
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 4263
***************************************
