++ Thanks for your response.

I only started using PERL5OPT a few weeks ago because I was sick of having to add those pragmata whenever I wanted a quick one-liner.

The "perlrun: PERL5OPT" documentation starts:

"Command-line options (switches). Switches in this variable are treated as if they were on every Perl command line."

I took this to mean that (with my current PERL5OPT settings)

perl -E '...'
[download]

would be expanded to

perl -Mstrict -Mwarnings -Mautodie -E '...'
[download]

I ran quite a few tests and, when satisfied everything worked OK, modified my .bash_profile so that it would always be available.

It never occurred to me that this would affect scripts; however, following your comments, I've run additional script tests and it does appear that my shebang line

#!/usr/bin/env perl
[download]

is being altered to

#!/usr/bin/env perl -Mstrict -Mwarnings -Mautodie
[download]

As I always add strict and warnings to every script, and often add autodie, this is not a problem for me. So, while I thank you for alerting me to this, I will continue to use PERL5OPT as I'm currently doing unless I come across a good reason for not doing so.

"It makes your scripts non-portable."

Perhaps you could expand on this. I'm failing to see any portability issues.

Hi kcott,

I assume what the AM is talking about is that scripts you write on your machine can omit warnings, strict and autodie, and if you copy that script to another machine - or even run it as another user - those pragmas will not be in effect there, altering the behavior of your scripts.

Also, scripts you copy onto your machine are now suddenly running with autodie, which will also change their behavior.

Regards,
-- Hauke D

G'day Hauke,

++ Thanks for the feedback. I've discontinued using PERL5OPT. See my response to AM tagged [PERL5OPT Resolution].

— Ken

if they were on every Perl command line means indeed every! oneliners, shebangs and even filetype associations on some unfortunate OS

If you remember to put your desiderata in all your scripts too I see no problems.

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

G'day Discipulus,

++ Thanks for the feedback. I've discontinued using PERL5OPT. See my response to AM tagged [PERL5OPT Resolution].

— Ken

After reading the responses by ++haukex^{Re^4: this thread} and ++Discipulus^{Re^4: this thread}, I now have:

PERL5OPT=
[download]

in .bash_profile (whence it's exported via set -a). And

alias perlo='perl -Mstrict -Mwarnings -Mautodie=:all'
[download]

[perlo = perl + options] in .bash_aliases (which is sourced by .bash_profile).

While I don't think it would actually make any of my scripts "non-portable", I can foresee issues with 3rd party scripts: t/*.t scripts leapt to mind as an obvious example.

Thanks again for alerting me to this: I have discontinued using PERL5OPT.

Mostly good advice, but I would advise STRONGLY against putting anything in PERL5OPT. It makes your scripts non-portable.

This is plain rubbish. The PERL5OPT environment variable doesn't have anything to do with portability, but with the current (application dependant, personal, temporal) options for perl, which might also be provided on the command line.

If you set up your PERL5OPT, you should know what's in there. If you distribute a suite of perl scripts relying on some value in PERL5OPT, you should inform your audience/customers about its rationale and sensible values. PERL5OPT is an environment variable, same as PERLINC (the latter having a default value). They only have effect if a) perl b) your scripts are already ported/portable.

G'day shmem,

++ That goes some way to corroborating my «I don't think it would actually make any of my scripts "non-portable"».

Tired of continually having to add ' -E to multiple perlo calls when testing, I wrote the alias [perle = perl + options and execute] to do it for me.

There are certain local usages of Perl where I don't want these pragmata: when using B::Deparse being a prime example. In these cases, having PERL5OPT set would be less than optimal. As these have, more or less, boilerplate command lines, I wrote the aliases [perlb = perl + B::Deparse] (which includes the '-p' option, to print extra parentheses — useful when checking complex predence rules) and [perlr = perl + B::Deparse raw] (which includes no options — useful when seeing how the code is parsed without the distraction of a forest of parentheses).

My .bash_aliases (sourced by .bash_profile) now includes:

alias perlo='perl -Mstrict -Mwarnings -Mautodie=:all'
alias perle='perl -Mstrict -Mwarnings -Mautodie=:all -E'
alias perlb='perl -MO=Deparse,-p -e'
alias perlr='perl -MO=Deparse -e'
[download]

Now I can write, for example:

$ perlo -E 'my $x; $x = 41; ++$x; say $x'
42
$ perle 'my $x; $x = 41; ++$x; say $x'
42
$ perlb 'my $x; $x = 41; ++$x; say $x'
my($x);
($x = 41);
(++$x);
$x->say;
-e syntax OK
$ perlr 'my $x; $x = 41; ++$x; say $x'
my $x;
$x = 41;
++$x;
$x->say;
-e syntax OK
[download]

I also considered other common usages that might have boilerplate command lines. I often use Perl as a handy calculator (e.g. perl -E 'say($calculation_result)'). I wrote the function [perls = perl + say()].

My .bash_functions (also sourced by .bash_profile) now includes:

perls () {
    eval "echo \`perl -T -Mstrict -Mwarnings -Mautodie=:all -E '
        my \$ev = eval \"$@\";
        say defined \$ev ? \"\$ev\" : \"$@\";
    '\`"
}
[download]

Now I can write, for example:

$ perls 1 + 1
2
$ perls 67 / 33
2.03030303030303
$ perls \(67 / 33\) + 1
3.03030303030303
$ perls '(67 / 33) + 1'
3.03030303030303
$ perls 'my \\\$x; \\\$x = 41; ++\\\$x'
42
$ perls `perle 'my $x; $x = 41; ++$x; say $x'`
42
$ perle 'my $x; $x = 41; ++$x; say $x'
42
$ perls Hello, world!
Hello, world!
[download]

Setting PERL5OPT globally is not useful for me; however, I don't discount its use in limited scope.

— Ken