@eplist[0 .. 2];
[download]

See also Basic debugging checklist and How do I compose an effective node title?

G'day jmckinzie,

Welcome to the Monastery.

"Need script help"

Yes, indeed! :-)

While I'm just guessing here, it looks like you've started with a Bourne-like shell script and attempted to convert it to Perl. Whether or not that's true, what you've posted is littered with problems.

I suggest you start by reading "perlintro -- Perl introduction for beginners". Then implement what you've learned.

The "Safety net" will highlight many issues and in most cases will tell you where they are and how to fix them. I expect the most common to be messages like:

Global symbol "$x" requires explicit package name (did you forget to d
+eclare "my $x"?) at <location>
[download]

Then, you'll probably get almost as many:

Bareword "xxx" not allowed while "strict subs" in use at <location>
[download]

These probably just require quoting (see "perlop: Quote and Quote-like Operators").

When you get to the "Files and I/O" section, see how the example code differs from yours and follow the links therein for further discussion. Your posted line

open(DATA, "<$tmpfile") or die "Can't open data";
[download]

has additional problems.

DATA (beyond having global scope and all the problems associated with global variables) is actually special to Perl. It doesn't exist by default:

$ perl -E 'say for <DATA>'
Name "main::DATA" used only once: possible typo at -e line 1.
readline() on unopened filehandle DATA at -e line 1.
$
[download]

But it will come into existence in circumstances that aren't immediately obvious (especially for those new to the language).

$ perl -E 'say for <DATA>; __END__'
$
[download]

It's good that you've attempted to check I/O problems with "... or die "...";"; however, the message that will be output identifies neither the file nor the problem. Hand-crafting such checks is tedious and error-prone. Let Perl do this work for you with the autodie pragma.

Having addressed all of these basic problems, you can now start looking at issues related to logic, control flow, and so on. The main one that leaps out me is the two assignments to @eplist without any intervening use of that variable.

Throughout my response, I've used examples like:

perl -E '...'
[download]

You should note that I have the environment variable, $PERL5OPT, set to "-Mstrict -Mwarnings -Mautodie" (see "perlrun: ENVIRONMENT"). To get the same output as me, either set this variable in your environment, or write the examples like:

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

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

++ 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.

— 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.

— Ken

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.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

my @servers = qw( foo bar baz quux );
while (@servers) {
   my @group = splice @servers, 0, 3;
   print "group: @group\n";
}
[download]

Also, since you're writing in Perl and not a shell script, you can do a way with the tempfile and grepping.

open my $DATA, "wlsendpts blah blah blah |" or die;
while (<$DATA>) {
   next unless /End/ && !/tcp3/ && /reg/;
   # do whatever with this line of output
}
[download]