[32986] in Perl-Users-Digest
Perl-Users Digest, Issue: 4262 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 8 21:09:18 2014
Date: Fri, 8 Aug 2014 18:09: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 Fri, 8 Aug 2014 Volume: 11 Number: 4262
Today's topics:
Re: Declaring and using global variables <news@todbe.com>
How can I point to different Perl compilers based on OS <richardn@nospam.com>
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 <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 <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 <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 <rweikusat@mobileactivedefense.com>
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 <gravitalsun@hotmail.foo>
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>
mojolicious(+Nginx) does not work in non-blocking way <gypark@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 08 Aug 2014 00:18:13 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: Declaring and using global variables
Message-Id: <ls1tjj$65j$1@dont-email.me>
On 8/7/2014 23:32, Tim McDaniel wrote:
> It's a bit late and I'm a bit tired, I've never used "our" and rarely
> used "use vars", and I want to have the best style.
> Can I and should I just replace
> use vars qw($lamp $food $water);
> with
> our ($lamp, $food, $water);
> ? We don't have more than one package in a file and we do "use vars"
> only at top level, so I think the difference in scoping between the
> two should not matter.
Don't see why not. I seldom use 'use vars' in my code - I think of it
more like a kludge.
> Other than "use Adventure::Cave;", should I be doing something in
> Player before referring to $Adventure::Cave::lamp?
Like what?
A simple little test case should answer your questions.
perlfunc man page:
our EXPR
our TYPE EXPR
our EXPR : ATTRS
our TYPE EXPR : ATTRS
"our" associates a simple name with a package variable in the current
package for use within the current scope. When "use strict 'vars'" is in
effect, "our" lets you use declared global variables without qualifying
them with package names, within the lexical scope of the "our"
declaration. In this way "our" differs from "use vars", which is package
scoped.
Unlike "my", which both allocates storage for a variable and associates
a simple name with that storage for use within the current scope, "our"
associates a simple name with a package variable in the current package,
for use within the current scope. In other words, "our" has the same
scoping rules as "my", but does not necessarily create a variable.
If more than one value is listed, the list must be placed in
parentheses.
our $foo;
our($bar, $baz);
An "our" declaration declares a global variable that will be visible
across its entire lexical scope, even across package boundaries. The
package in which the variable is entered is determined at the point of
the declaration, not at the point of use.
------------------------------
Date: Fri, 8 Aug 2014 09:26:33 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4e99faaf57fa849897e0@news.eternal-september.org>
Hi all,
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. I'd like to point the script instead to a networked install of Perl which I
know is 64-bit. But the problem is that some users use linux and some use AIX and any
compiler I point to will only work for one OS.
Of course, I can simply maintain two scripts (one for linux and one for AIX) which are
identical except for the first line which points to the right Perl for the desired OS but is
there a cleaner way? A shell script front end can detect OS and then run the appropriate
script but there still needs to be those two scripts it can pick from.
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
------------------------------
Date: Fri, 08 Aug 2014 16:43:26 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <87oavv9ech.fsf@sable.mobileactivedefense.com>
Richard Nicholas <richardn@nospam.com> writes:
> 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. I'd like
> to point the script instead to a networked install of Perl which I
> know is 64-bit. But the problem is that some users use linux and some
> use AIX and any compiler I point to will only work for one OS.
>
> Of course, I can simply maintain two scripts (one for linux and one
> for AIX) which are identical except for the first line which points to
> the right Perl for the desired OS but is there a cleaner way?
The two obvious ideas would be
- require a 'standardized' name for a suitable Perl, eg
/usr/bin/perl64
- use a shell script as interpreter which does an exec of the
actual perl binary based on a suitable test, eg, uname
------------------------------
Date: Fri, 8 Aug 2014 11:10:57 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4eb276817a420b9897e1@news.eternal-september.org>
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.
> - use a shell script as interpreter which does an exec of the
> actual perl binary based on a suitable test, eg, uname
>
I think this is what I was looking for. I was going to use the shell script to call the Perl
script, but I didn't think about using it to call the compiler. I didn't know I could call
/path/perl script.pl because I thought the path for the compiler had to be inside script.pl
on the first line. But I just experimented and it looks like I can call the Perl compiler I
want, even if the first line of the script.pl is: #!/usr/bin/perl. I.e. the path inside the
script must be ignored if you call a specific Perl directly. Thanks!
Richard Nicholas
------------------------------
Date: Fri, 08 Aug 2014 17:31:21 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <87k36j9c4m.fsf@sable.mobileactivedefense.com>
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.
>
>> - use a shell script as interpreter which does an exec of the
>> actual perl binary based on a suitable test, eg, uname
>>
>
> I think this is what I was looking for. I was going to use the shell script to call the Perl
> script, but I didn't think about using it to call the compiler. I didn't know I could call
> /path/perl script.pl because I thought the path for the compiler had to be inside script.pl
> on the first line. But I just experimented and it looks like I can call the Perl compiler I
> want, even if the first line of the script.pl is: #!/usr/bin/perl. I.e. the path inside the
> script must be ignored if you call a specific Perl directly. Thanks!
I was actuallt thinking about using
#!/your/script
instead of
#!/usr/bin/perl
the script would then determine the location of a suitable perl and end
with
exec /path/to/perl "$@"
------------------------------
Date: Fri, 8 Aug 2014 13:38:49 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4ed539912e9dc39897e2@news.eternal-september.org>
In article <87k36j9c4m.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
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.
> >
> >> - use a shell script as interpreter which does an exec of the
> >> actual perl binary based on a suitable test, eg, uname
> >>
> >
> > I think this is what I was looking for. I was going to use the shell script to call the Perl
> > script, but I didn't think about using it to call the compiler. I didn't know I could call
> > /path/perl script.pl because I thought the path for the compiler had to be inside script.pl
> > on the first line. But I just experimented and it looks like I can call the Perl compiler I
> > want, even if the first line of the script.pl is: #!/usr/bin/perl. I.e. the path inside the
> > script must be ignored if you call a specific Perl directly. Thanks!
>
> I was actuallt thinking about using
>
> #!/your/script
>
> instead of
>
> #!/usr/bin/perl
>
> the script would then determine the location of a suitable perl and end
> with
>
> exec /path/to/perl "$@"
I'm not sure I understand this approach. My Perl script immediately branches off to some
other script called /your/script which will then branch back to the original Perl script?
Richard Nicholas
------------------------------
Date: Fri, 08 Aug 2014 20:19:06 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <87a97elrh1.fsf@sable.mobileactivedefense.com>
Richard Nicholas <richardn@nospam.com> writes:
> In article <87k36j9c4m.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> 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.
>> >
>> >> - use a shell script as interpreter which does an exec of the
>> >> actual perl binary based on a suitable test, eg, uname
>> >>
>> >
>> > I think this is what I was looking for. I was going to use the shell script to call the Perl
>> > script, but I didn't think about using it to call the compiler. I didn't know I could call
>> > /path/perl script.pl because I thought the path for the compiler had to be inside script.pl
>> > on the first line. But I just experimented and it looks like I can call the Perl compiler I
>> > want, even if the first line of the script.pl is: #!/usr/bin/perl. I.e. the path inside the
>> > script must be ignored if you call a specific Perl directly. Thanks!
>>
>> I was actuallt thinking about using
>>
>> #!/your/script
>>
>> instead of
>>
>> #!/usr/bin/perl
>>
>> the script would then determine the location of a suitable perl and end
>> with
>>
>> exec /path/to/perl "$@"
>
> I'm not sure I understand this approach. My Perl script immediately
> branches off to some other script called /your/script which will then
> branch back to the original Perl script?
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.
------------------------------
Date: Fri, 8 Aug 2014 15:30:26 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4eef5e72afa8ac9897e3@news.eternal-september.org>
In article <87a97elrh1.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
>
> Richard Nicholas <richardn@nospam.com> writes:
> > In article <87k36j9c4m.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> > 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.
> >> >
> >> >> - use a shell script as interpreter which does an exec of the
> >> >> actual perl binary based on a suitable test, eg, uname
> >> >>
> >> >
> >> > I think this is what I was looking for. I was going to use the shell script to call the Perl
> >> > script, but I didn't think about using it to call the compiler. I didn't know I could call
> >> > /path/perl script.pl because I thought the path for the compiler had to be inside script.pl
> >> > on the first line. But I just experimented and it looks like I can call the Perl compiler I
> >> > want, even if the first line of the script.pl is: #!/usr/bin/perl. I.e. the path inside the
> >> > script must be ignored if you call a specific Perl directly. Thanks!
> >>
> >> I was actuallt thinking about using
> >>
> >> #!/your/script
> >>
> >> instead of
> >>
> >> #!/usr/bin/perl
> >>
> >> the script would then determine the location of a suitable perl and end
> >> with
> >>
> >> exec /path/to/perl "$@"
> >
> > I'm not sure I understand this approach. My Perl script immediately
> > branches off to some other script called /your/script which will then
> > branch back to the original Perl script?
>
> 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. 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.
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?
Richard Nicholas
------------------------------
Date: Fri, 08 Aug 2014 21:55:08 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <8738d61z2r.fsf@sable.mobileactivedefense.com>
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' ...
> 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
------------------------------
Date: Fri, 8 Aug 2014 16:12:56 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <MPG.2e4ef94f383804459897e4@news.eternal-september.org>
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 "$@"
> > 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 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.
Richard Nicholas
------------------------------
Date: Fri, 08 Aug 2014 22:48:35 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <877g2ifya4.fsf@sable.mobileactivedefense.com>
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).
------------------------------
Date: Fri, 08 Aug 2014 14:49:38 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <ls3gle$rrm$1@dont-email.me>
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__
------------------------------
Date: Sat, 09 Aug 2014 02:43:44 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <ls3nc6$ug4$1@news.ntua.gr>
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'
------------------------------
Date: Fri, 08 Aug 2014 17:37:09 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <lnoavuqz0q.fsf@nuthaus.mib.org>
"$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.
--
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: Fri, 08 Aug 2014 17:42:05 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <lnk36iqysi.fsf@nuthaus.mib.org>
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.
>> - 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.)
--
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: Fri, 8 Aug 2014 00:57:22 -0700 (PDT)
From: Raymundo <gypark@gmail.com>
Subject: mojolicious(+Nginx) does not work in non-blocking way
Message-Id: <605f3513-5ca4-4421-97cf-75b4ce84c837@googlegroups.com>
Hello,
At first, I'm sorry I'm not good at English.
I'm making a Mojolicious app.
My controller does some job using Mojo::UserAgent and uses the result when it makes the output.
my $ua = Mojo::UserAgent->new();
my $tx = $ua->head( $location );
my $result;
if ( $tx->res->code eq '200' ) {
$result = 'good';
}
else {
$result = 'bad';
}
# pass the result to the renderer's stash
$self->render( result => $result );
This code works well. **It works on both my local machine and the server**.
Next, I tried to make this `$ua->head()` non-blocking way, because it could take long time to complete. (I'm a novice and this is my first time to try non-blokcing code using Mojo, for your reference)
my $ua = Mojo::UserAgent->new();
my $result;
$self->render_later;
$ua->head( $location => sub {
my ($ua, $tx) = @_;
if ( $tx->res->code eq '200' ) {
$result = 'good';
}
else {
$result = 'bad';
}
$self->render( result = $result );
});
Mojo::IOLoop->start unless Mojo::IOLoop->is_running;
**This approach also works well in my local machine** (MacBook OSX 10.9.4, Perl 5.18, Standalone using morbo).
However, **when I launch this code in the server, the server responds with "404 not found".**
This server uses Nginx proxy, which forwards requests to working nodes.
`browser -- Nginx -- Mojolicious App`
So, I guess this proxy is related to my problem, but I have no idea how to fix it. I don't know even where I have to start from to find the exact cause.
For your info, Usually, Mojo app responds with its own 'not-found' page. But in this case the browser shows only blank page.
Any advice would be appreciated.
Thank you.
------------------------------
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 4262
***************************************
