The most perfect beginning

[wana]

I was looking at the Perl t-shirts at
http://www.thinkgeek.com/tshirts/coder/321a/ and I noticed that the
shirt says:

#!/usr/bin/perl -w
use strict;

I was told that:

#!/usr/bin/perl

use strict;
use warnings;

is better. Also, I was told that I should use -T, especially in cases
like CGI where many users may run a program, which I found out was not
as simple as adding the -T to the first line.

I was wondering what people think is the most perfect general
beginning to a Perl program that could be used in most or all
programs. This would include whatever flags, pragmas and modules
might be useful and important.

Thanks for any responses!

wana

 

[Tad McClellan]

On 11/3/04 11:27, wana wrote:

I always start with:

[snip]


I always start with this "skeleton" program:

--------------------------
#!/usr/bin/perl
# progname - one-line description of what progname does
use warnings;
use strict;

while ( <> ) {


print;
}
--------------------------


Most of my programs are "rip through a file and do something with each line".

I've adopted the convention on the 2nd line so that I can use File::Find
to identify and list every Perl program that I've ever written.

 

[A. Sinan Unur]

(e-mail address removed) (wana) wrote in

I was wondering what people think is the most perfect general
beginning to a Perl program that could be used in most or all
programs. This would include whatever flags, pragmas and modules
might be useful and important.

Depends.

At a minimum, you should have

use strict;
use warnings;

At your level, you should also consider

use diagnostics;

As for -w vs warnings, these days the latter is preferable because it
allows you to fine tune what warnings you receive etc based on the scope.

Sinan,

 

[Todd de Gruyl]

I was looking at the Perl t-shirts at
http://www.thinkgeek.com/tshirts/coder/321a/ and I noticed that the
shirt says:

#!/usr/bin/perl -w
use strict;

I was told that:

#!/usr/bin/perl

use strict;
use warnings;

is better.

Yes. use warnings was added in Perl 5.6. The camel code on the shirt
dates from about the same time as 5.6 was introduced, as far as I can tell.

Also, I was told that I should use -T, especially in cases
like CGI where many users may run a program, which I found out was not
as simple as adding the -T to the first line.

If you are running a script where you cannot guarantee the input, always
use the -T flag.

To find out more:
perldoc perlsec
perldoc perlrun

I was wondering what people think is the most perfect general
beginning to a Perl program that could be used in most or all
programs. This would include whatever flags, pragmas and modules
might be useful and important.

I always start with:

#!/usr/bin/perl
use warnings;
use strict;

and then add on to that as I need to. That's really the only 'perfect
general beginning' in my opinion.

 

[Anno Siegel]

[...]

I was wondering what people think is the most perfect general
beginning to a Perl program that could be used in most or all
programs. This would include whatever flags, pragmas and modules
might be useful and important.

Here is my current template for a Perl program:

#!/usr/local/bin/perl
use strict; use warnings; $| = 1;
use Vi::QuickFix;

exit; #########################################################

__END__

Comments:

Setting $| in the main program helps keeping the visible stdout and
stderr in sync. If you do mass output on stdout, switch it off.

Vi::QuickFix is a module that helps Vim users such as yours truly
find the locations of Perl errors and warnings (including those from
modules loaded by your program) -- that is, Vim finds them with the
aid of a file Vi::QuickFix leaves around. Available on CPAN.

Filling in the form, everything executable comes before "exit" (duh),
sub definitions go below the "###########..." (slightly shortened for
usenet). "BEGIN" (including "use") "END" and possibly "CHECK" and
"INIT" can go anywhere, preferably right on top, or near the place
that motivates them.

Anno

 

[Anno Siegel]

[...]

I was wondering what people think is the most perfect general
beginning to a Perl program that could be used in most or all
programs. This would include whatever flags, pragmas and modules
might be useful and important.

Here is my current template for a Perl program:

#!/usr/local/bin/perl
use strict; use warnings; $| = 1;
use Vi::QuickFix;

exit; #########################################################

__END__

Comments:

Setting $| in the main program helps keeping the visible stdout and
stderr in sync. If you do mass output on stdout, switch it off.

Vi::QuickFix is a module that helps Vim users such as yours truly
find the locations of Perl errors and warnings (including those from
modules loaded by your program) -- that is, Vim finds them with the
aid of a file Vi::QuickFix leaves around. Available on CPAN.

Filling in the form, everything executable comes before "exit" (duh),
sub definitions go below the "###########..." (slightly shortened for
usenet). "BEGIN" (including "use") "END" and possibly "CHECK" and
"INIT" can go anywhere, preferably right on top, or near the place
that motivates them. If you must know

Anno

 

[wana]

The 'warnings' pragma did not exist in early versions of perl5. The -w
turns warnings on regardless of which version of perl you're running.


-T is definitely a good idea for CGI, or in any context where outside
input/data needs to be treated like toxic waste that must be purified
before it is used. That doesn't mean it's necessary, or even the best
option, in all cases, though.


You're question doesn't make much sense. I frequently use the Getopt::*
modules in a lot of my scripts, but they don't make sense in all of my
apps, so I wouldn't recommend them as a standard "opening" to a program.
Most modules work this way. Use the modules that make your program
better.

That's true. I guess my question would have been better stated as asking
people for standard templates that they use to start off most programs. I
am really enjoying reading the responses. At least everyone can agree on:

#!/usr/bin/perl
use strict;
use warnings;

I have a module I wrote for self use that I include in every single program
because it encapsulates some common actions that would normally take 3 or 4
lines of code.

Even using the -wTMstrict in your scripts isn't as valuable as knowing
*exactly* *why* you *should* be using them. Doing things just because
you saw someone else do them is, to resurrect a cliche', cargo cult
programming.

The chapter in 'Programming Perl' describes writing a module like filling
out a contract. You don't have to fully understand everything in it to
write one, just fill in the details.

writing Visual C++ programs is the worst extreme. I used to write my little
pockets of code surrounded by a sea of incomprehensible Microsoft code. As
long as I stayed on the path, I was usually safe.

 

[Matt Garrish]

On 11/3/04 11:27, wana wrote:

I always start with:

[snip]


I always start with this "skeleton" program:

--------------------------
#!/usr/bin/perl
# progname - one-line description of what progname does
use warnings;
use strict;

while ( <> ) {


print;
}
--------------------------


Most of my programs are "rip through a file and do something with each
line".

I've adopted the convention on the 2nd line so that I can use File::Find
to identify and list every Perl program that I've ever written.

The importance of which can't be stressed enough. I write so many scripts to
do the same kind of thing, and usually only revisit them once a year
(cyclical pattern to the work I do). Without a description of what the
script does, it can be a pain to remember why you wrote two sorting
programs, for example, and which you should be using for what.

Matt

 

[J. Romano]

I was wondering what people think is the most perfect general
beginning to a Perl program that could be used in most or all
programs. This would include whatever flags, pragmas and modules
might be useful and important.

I don't do this very often on my own scripts, but when I end up
having to maintain a script that someone else wrote, I sometimes add
the line:

use Fatal qwvoid open opendir chdir rename);

near the top of the script.

This line will terminate the program with a useful error message if
any of the commands mentions (that is, open(), opendir(), chdir(), or
rename()) fail and the return value is not handled. The ":void"
keyword prevents the script from exiting as long as the return value
is handled, such as:

open(FILE, ">/blah.txt") or die "Cannot write to blah.txt: $!";

Any decent Perl programmer should ALWAYS check the return values of
these functions. I can't stress this enough. I have seen several
times where a programmer thinks that some Perl code like:

open(OUT, "> path/data.txt");
my ($key, $value);
while (($key, $value) = each %hash)
{
print OUT "$key:$value\n";
}

"won't work" because the each() function doesn't work the way I told
him it would. In reality, it is because the open() function failed.

I look at the other programmer's code and say, "You should ALWAYS
check the return value of an open() statement." The other programmer
will counter, saying something like: "There is NO reason for it not
to work."

Nevertheless, I force him add "or die "Cannot write to data.txt:
$!" and then, when we re-run the script, we find that the open()
command failed (due to an incorrect path or possibly for some other
reason that we didn't think of before).

Unfortunately, this "there is NO reason for it not to work"
attitude that too many programmers have make them think that the bug
lies in another part of the program, like in the call to each(). As a
result, I'm often told that another part of the Perl script won't work
they way I explained it would simply because the other programmer
never even stops to consider that their call to open(), opendir(),
chdir(), or rename() could ever fail.

And because some programmers STILL won't check the return value, it
is a pain to inherit and maintain their code. That is why I will
sometimes add the line:

use Fatal qwvoid open opendir chdir rename);

near the top of a script, especially if the script is so long that it
is difficult to change every call to the listed functions. If they do
check all the return values of the listed functions (as every
programmer should), then including the Fatal module should have no
effect. But if they don't (which happens all too often,
unfortunately), this line will catch their errors (and report a useful
error message) despite the fact that they don't.

You may even consider putting this line in the scripts you write
yourself, just in case you ever forget to handle the return value.
Hopefully this would never happen, but mistakes do happen
occasionally.

I hope this helps, wana.

-- Jean-Luc