UPDATE: I've mostly left this Meditation as it was 15 years ago, but since then it's also appeared in Mastering Perl and I'm updating it at briandfoy.github.io.
brian's Guide to Solving Any Perl Problem
Follow this guide and save your sanity
I believe in three things:
- It is not personal
-
Forget about code ownership. You may think yourself an artist, but
even the old Masters produced a lot of crap. Everybody's code is
crap, which means my code is crap and your code is crap. Learn to
love that. When you have a problem, your first thought should be
``Something is wrong with my crappy code''. That means you do not get
to blame perl. It is not personal.
-
Forget about how you do things. If the way you did things worked,
you would not be reading this. That is not a bad thing. It is just
time to evolve. We have all been there.
- Personal responsibility
-
If you have a problem with your script it is just that---your problem.
You should do as much to solve it by yourself as you can. Remember,
everyone else has their own scripts, which means they have their own
problems. Do your homework and give it your best shot before you
bother someone else with your problems. If you honestly try
everything in this guide and still cannot solve the problem, you have
given it your best shot and it is time to bother someone else.
- Change how you do things
-
Fix things so you do not have the same problem again. The problem is
probably how you code, not what you code. Change the way you do
things to make your life easier. Do not make Perl adapt to you
because it will not. Adapt to Perl. It is just a language, not a way
of life.
- Does your script compile with strictures?
-
If you are not already using strictures, turn it on. Perl gurus are
gurus because they use strict which leaves them more time to solve
other problems, learn new things, and upload working modules to CPAN.
-
You can turn on strictures within the code with the strict pragma.
-
use strict;
-
You can turn on strictures from the command line with perl's -M
switch.
-
perl -Mstrict script.pl
-
You may be annoyed at strictures, but after a couple of weeks of
programming with them turned on, you will write better code, spend
less time chasing simple errors, and probably will not need this
guide.
- What is the warning?
-
Perl will warn you about a lot of questionable constructs. Turn on
warnings and help Perl help you.
-
You can use perl's -w switch in the shebang line.
-
#!/usr/bin/perl -w
-
You can turn on warnings from the command line.
-
perl -w script.pl
-
You can use lexical warnings with all sorts of interesting features.
See warnings for the details.
-
use warnings;
-
If you do not understand a warning, you can look up a verbose version
of the warning in perldiag or you can use the diagnostics pragma in
your code.
-
use diagnostics;
- Solve the first problem first!
-
After you get error or warning messages from perl, fix the first
message then see if the perl still issues the other messages. Those
extra messages may be artifacts of the first problem.
- Look at the code before the line number in the error message!
-
Perl gives you warning messages when it gets worried and not before.
By the time perl gets worried the problem has already occurred and the
line number perl is on is actually after the problem. Look at the
couple of expressions before the line number in the warning.
- Is the value what you think it is?
-
Do not guess! Actually examine the value right before you want to use
it in an expression. The best debugger in the universe is print.
-
print STDERR "The value is ]$value]\n";
-
I enclose $value in braces so I can see any leading or trailing
whitespace or newlines.
-
If I have anything other than a scalar, I use Data::Dumper to print
the data structures.
-
require Data::Dumper;
-
print STDERR "The hash is ", Data::Dumper::Dumper( \%hash ), "\n";
If the value is not what you think it is, back up a few steps and try
again! Do this until you find the point at which the value stops
being what you think it should be!
-
You can also use the built-in perl debugger with perl's -d switch. See
perldebug for details.
-
perl -d script.pl
-
You can also use other debuggers or development environments, like a
ptkdb (a graphical debugger based on Tk), Komodo (ActiveState's Perl
IDE based on Mozilla), of Affrus on MacOS X.
- Are you using the function correctly?
-
I have been programming Perl for quite a long time and I still look at
perlfunc almost every day. Some things I just cannot keep
straight, and sometimes I am so sleep-deprived that I take leave of
all of my senses and wonder why sprintf() does not print to the
screen.
-
You can look up a particular function with the perldoc command and its
-f switch.
-
perldoc -f function_name
-
If you are using a module, check the documentation to make sure you
are using it in the right way. You can check the documentation for
the module using perldoc.
-
perldoc Module::Name
- Are you using the right special variable?
-
Again, I constantly refer to perlvar. Well, not really since I
find The Perl Pocket Reference much easier to use.
- Do you have the right version of the module?
-
Some modules change behavior between versions. Do you have the
version of the module that you think you have? You can check
the module version with a simple perl one-liner.
-
perl -MModule::Name -le 'print Module::Name->VERSION';
-
If you read most of your documentation off of the local machine,
like at http://www.perldoc.com or http://search.cpan.org, then
you are more likely to encounter version differences in documentation.
- Have you made a small test case?
-
If you are trying something new, or think a particular piece of
code is acting funny, write the shortest possible program to do
just that piece. This removes most of the other factors from
consideration. If the small test program does what it thinks it
does, the problem probably is not in that code. If the program
does not do what you think it does, then perhaps you have found
your problem.
- Did you check the environment?
-
Some things depend on environment variables. Are you sure that
they are set to the right thing? Is your environment the same
that the program will see when it runs? Remember that programs
intended for CGI programs or cron jobs may see different environments
than those in your interactive shell, especially on different
machines.
-
Perl stores the environment in %ENV. If you need one of those
variables, be ready to supply a default value if it does not
exist, even if only for testing.
-
If you still have trouble, inspect the environment.
-
require Data::Dumper;
print STDERR Data::Dumper::Dumper( \%ENV );
- Have you checked Google?
-
If you have a problem, somebody else has probably had that problem.
See if one of those other people posted something to the usenet group
comp.lang.perl.misc by searching Google Groups
(http://groups.google.com). The difference between people who ask
questions on usenet and those who answer them is the ability to use
Google Groups effectively.
- Have you profiled the application?
-
If you want to track down the slow parts of the program, have you
profiled it? Let Devel::SmallProf do the heavy lifting for you. It
counts the times perl executes a line of code as well as how long it
takes and prints a nice report.
- Which test fails?
-
If you have a test suite, which test fails? You should be able to
track down the error very quickly since each test will only exercise a
little bit of code.
-
If you don't have a test suite, why not make one? If you have a
really small script, or this is a one-off script, then I will not make
you write a couple of tests. Anything other than that could really
benefit from some test scripts. Test::Harness makes this so simple
that you really have no excuse not to do it. If you do not have the
time, perhaps you are wasting too much time debugging scripts without
tests. MakeMaker is just not for modules after all.
- Did you talk to the bear?
-
Explain your problem aloud. Actually say the words.
-
For a couple of years I had the pleasure of working with a really good
programmer who could solve almost anything. When I got really stuck I
would walk over to his desk and start to explain my problem. Usually
I didn't make it past the third sentence without saying ``Never
mind---I got it''. He almost never missed either.
-
Since you will probably need to do this so much, I recommend some sort
of plush toy to act as your Perl therapist so you do not annoy your
colleagues. I have a small bear that sits on my desk and I explain
problems to him..
- Does the problem look different on paper?
-
You have been staring at the computer screen, so maybe a different
medium will let you look at things in a new way. Try looking at
a print-out of your program.
If you don't want to use dead trees, try looking at the source without syntax highlight, or even in a different editor. Change up the way it looks and the fonts you use so you see different patterns.
- Have you watched The Daily Show with Jon Stewart?
-
Seriously. Perhaps you do not like Jon Stewart, so choose something
else. Take a break. Stop thinking about the problem for a bit and
let your mind relax. Come back to the problem later and the fix may
become immediately apparent.
- Have you packed your ego?
-
If you still have not made it this far, the problem may be
psychological. You might be emotionally attached to a certain part of
the code, so you do not change it. You might also think that everyone
else is wrong but you. When you do that, you do not seriously
consider the most likely source of bugs---yourself. Do not ignore
anything. Verify everything.
--
brian d foy <bdfoy@cpan.org>
Re: brian's Guide to Solving Any Perl Problem
by ysth (Canon) on Jul 20, 2004 at 22:05 UTC
|
Don't forget to look at the code after the line number in the message, too. Compare:
$ cat -n elsif.pl
1 use strict;
2 use warnings;
3
4 our $foo;
5
6 if ($^O eq "23niWSM") {
7 print "bugaboo\n";
8 }
9 elsif ($foo eq "bar") {
10 print "foobar\n";
11 }
$ perl elsif.pl
Use of uninitialized value in string eq at elsif.pl line 6.
$ cat -n if.pl
1 use strict;
2 use warnings;
3
4 our $foo;
5
6 if ($^O eq "23niWSM") {
7 print "bugaboo\n";
8 }
9 if ($foo eq "bar") {
10 print "foobar\n";
11 }
$ perl if.pl
Use of uninitialized value in string eq at if.pl line 9.
$ diff -u if.pl elsif.pl
--- if.pl 2004-07-20 15:00:49.412472000 -0700
+++ elsif.pl 2004-07-20 15:02:28.875492800 -0700
@@ -6,6 +6,6 @@
if ($^O eq "23niWSM") {
print "bugaboo\n";
}
-if ($foo eq "bar") {
+elsif ($foo eq "bar") {
print "foobar\n";
}
| [reply] [d/l] |
Re: brian's Guide to Solving Any Perl Problem
by water (Deacon) on Jul 21, 2004 at 02:48 UTC
|
Excellent writeup.
Off topic, I have to comment on introductory regexp:
s/girlfriend/wife/
Boy, one can encapsulate a huge amount of life change in 18 chars of perl!
Also it is good you did't have to use the /g modifier there!
| [reply] [d/l] [select] |
|
that can be shortened:
tr/glrind/wi/d;
=)
| [reply] [d/l] |
|
Could someone explain what exactly does it do?
tr/glrind/wi/d
Thanks.
| [reply] [d/l] |
|
|
Re: brian's Guide to Solving Any Perl Problem
by dws (Chancellor) on Jul 21, 2004 at 05:14 UTC
|
- Have you noticed areas of confusion?
- When trying to explain your code to others, have you noticed where they get confused? Have you noticed where you get confused? Spend some time in those areas. Try refactoring, simplifying, or rewriting until the confusion goes away.
| [reply] |
|
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by chanio (Priest) on Jul 21, 2004 at 04:50 UTC
|
A tough idea:
Having checked your code several times, you might know it by hard. So, rewrite it all again without peeping at the original one. Then compare boths scripts. There might be some significant differences, that might brainstorm or ( lateral think ) some solutions.
And if you are not able to know it by hard, it might be too long and should be shorten into more simple chunks of well structured code :)
.{\('v')/}
_`(___)' __________________________
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by inman (Curate) on Jul 21, 2004 at 12:35 UTC
|
Did you check the effective user?(in the same vein as Did you check the environment?)
A typical problem for people developing CGI code on Windows / IIS - My script runs from the command line but breaks when I run it under IIS. Problems like this usually relate to the script being run under a restricted user account. Scheduled jobs suffer from a similar range of problems.
Things that may not work if you have user/permissions issues include:
- Read/write to a local file.
- Accessing network shares.
- Read/write registry settings.
- Working with functionality that depends on any of the above e.g. ODBC.
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by greenFox (Vicar) on Jul 21, 2004 at 04:27 UTC
|
Great node ++. Some oft-repeated advice but it is great to have it all in one place, I can see this being a much linked to node and worthy of promotion to tutorials (it is currently under consideration for readmore tags).
On the topic of references I don't have The Perl Pocket Reference but I do have Perl in A Nutshell which lives permanently on my desk, I have long since given up trying to put it back on the shelf for exactly the reasons you describe.
You might be emotionally attached to a certain part of the code, so you do not change it.
A lot of writers fall into this same trap of emotional attachment "but I like this sentence/passage" and because they like it they can't see that it detracts from the piece of writing. The golden rule of editing is "be bloody ruthless", it seems like good advice for coding as well.
-- Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by crabbdean (Pilgrim) on Jul 22, 2004 at 11:15 UTC
|
Fantastic Node!! ++ A couple of suggestion I'd add, some in alignment with some of your own suggestions.
Is your code intuitively simple?: I've only been programming for a little while but one thing I found once I got use to the concepts/ideas the best solutions have a simple-ness about them. And often have less bugs. If you find your solution is a bit convaluted/verbose chances are there is a neater and cleaner way of doing it. By chance, my recent node 375782 is a perfect example of what I mean (a few suggestion but the final solution {thanks to tye} only required two small changes to a problem I'd been considering for quite a while). I love that about programming.
In addition to "Personal Responsibility" Make the effort to solve it yourself: Programming, the knowledge behind and the ability to research it are skills that are acquired in time. The time spent debugging and finding solutions is a skill unto itself. In time this skill develops and you get faster at it. The ability to research for yourself (to be self reliant) is a skill also. Later when you get a problem you can solve it in a matter of moments because of the problem-solving skills you've developed. And trust me this comes from experience ... I've NEVER EVER done a computer course or training. NOT ONE! I'm completely self taught. A skill that now has be challenging even some of the senior technicians at my work.
Take a shower: Hey it works for me! The break from the screen and code gives your mind time to relax, rethink. The water is meditative and soothing. I often walk out of the shower with my mind flowing with new ideas (excuse the pun!) Plus after 12+ hours in front of a monitor the hygiene is probably beneficial. :-)
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by TilRMan (Friar) on Jul 21, 2004 at 07:06 UTC
|
A quick googling found an earlier version which includes the copyright information. Alas, it is "all rights reserved." Is there any chance you would open this up with a less restrictive license, such as the Perl Artistic License, a Creative Commons license, or the GNU Free Documentation Licence?
Of course, I can give people a link or tell them to google it, but this is the kind of guide that you want to have hard copies of -- one for yourself and several to pass out to anybody who stops by.
| [reply] |
|
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by tilly (Archbishop) on Jul 20, 2004 at 20:58 UTC
|
In the line of verifying everything, you said that you did an s/girlfriend/wife/ but don't appear to have actually done it. :-P
Otherwise this is all good advice.
UPDATE: It's been done now.
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by JanneVee (Friar) on Jul 20, 2004 at 23:03 UTC
|
Most of these things also apply to any programming task in any language not just Perl. At a first glance the only thing that doesn't fit into any language is "Are you using the right special variable?". | [reply] |
|
| [reply] |
|
Yes, but other languages has profilers, docs and so on. These things are not perl only. :)
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by WuWei (Initiate) on Jul 27, 2004 at 04:54 UTC
|
In general, it's a good idea to declare variables using my instead of using a global or using local. It forces namespace and scope awareness and eliminates pernicious bugs caused by same-named variables with different scope. Practically anything you can do with a local or global variable, you can do with a change in design using my, and you'll get a much more robust design.
Also, in general, avoid exporting variables from modules. Exporting methods can sometimes be OK, although I still think it's better to say
use Foo::Bar;
...
my $barian = Foo::Bar->baz();
so the method's origin is clear.
Variable and method names should be communicative of the intended use; it's better for a name to be long and communicative than short and cryptic.
Document, document, document.
Also: I'm astonished no one's mentioned using functional spec's and test suites before now. (Visit this Joel Spolsky article and scroll down to the second headline, "Painless Functional Specifications," for information on the former; perldoc Test::Harness and perldoc LWP::UserAgent for details on the latter, and on user agents which are also an enormous boon to web developers seeking a means of testing functionality and sounding the alarm when things go wrong.) Writing a spec before the program saves loads of time and heartache, as well as keeping the MBA's and the techies on the same page. Similarly, fleshing out the spec into a test suite before any code gets written -- and continuing to flesh out the test suite while coding -- reduces the likelihood of bugs, increases confidence in the final product, and makes a predictable timeline actually possible. Ideally, you want to test as high up the call chain as possible, drilling down into the nitty gritty only when -- and to the extent that -- the need presents itself.
There are even times where it can be helpful to write a tiny program whose specific purpose is to test the syntax or the effect of some (for you) uncharted Perl functionality. I did this in my formative Perl years and it saved me an enormous amount of time.
Oh, and also it helps -- particularly if you're working in a country whose primary language is English -- not to comment your code in, say, Croatian. (Don't laugh, I actually inherited a project some years ago containing some sections of code in which this had been done!)
| [reply] [d/l] [select] |
|
Along similar lines as that last point, I'd find myself (particular for CPAN modules) always writing my APIs in American English, despite being in Australia.
It just makes life similar if everybody uses the same spelling for classes and methods. It's a swallowing your pride thing.
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by sfink (Deacon) on Jul 22, 2004 at 07:34 UTC
|
Any reason why you type all of
require Data::Dumper;
print Data::Dumper::Dumper(...);
rather than
use Data::Dumper;
print Dumper(...);
?
Also, in your particular example, I always prefer the output of Dumper(\%hash) to that of Dumper(%hash).
Recently, I've been sometimes using the even-less-typing-required use YAML; print Dump(...), but that requires actually installing YAML first. And I'm still not nearly as used to the YAML format as I am to Data::Dumper format.
| [reply] [d/l] [select] |
|
Most style guides I work under ask for the full package name of external functions, and I generally agree with that. I have found that I shouldn't expect others to know where all of these functions came from. Also, I don't have to keep track of every modules exports. Some decided to have the same names for things. Remember: @EXPORT is evil.
This way would cause a problem if someone wanted to use YAML as a drop in replacement, though.
--
brian d foy <bdfoy@cpan.org>
| [reply] |
|
Most style guides I work under ask for the full package name of external functions, and I generally agree with that. I have found that I shouldn't expect others to know where all of these functions came from.
I totally agree that you should know where a subroutine comes from, but i pretty strongly disagree with using FQ package names to acomplish that, and I definately don't think that using require is wise at all. There are two reasons for these opinions. The first has to do with encapsulation. When you use FQ subroutine names you are totally violating the encapsulation of your package code. Take the following contrived example:
Package Foo has two subs defined, BarA() and BarS(), BarA is defined for export, BarS is defined as a more or less private internal version. You want to use BarA(), so you write Foo::BarS() and then wonder why your program A) doesnt fail when it gets to that line, and B) why its just done something horrible to your data that BarA() promises not to do.
With use and explicit exports you dont have this problem. You EXPLICTLY request the export of a subroutine. Assuming the private version isnt in @EXPORT_OK then youll never blow your foot off by saying:
use Foo qw(BarS);
A second serious objection i have to using require like this is that requires are run time constructs. Your program could have half finished before it gets to the require only to fail, leaving your program in the tough position of having to recover, something that it may be bad at, which could leave your overall system in an indeterminate state. Wheras with use the error would have occured at compile time, and would have happened before almost anything else did, a situation much easier to recover gracefully from.
My personal feeling is that require is a badly named keyword. Most often when I see the keyword in use is when the code doesnt in fact "require" the module at all, but rather would just prefer it to be there. AFAICT when code really requires a module its much better to use it instead.
Anyway, good thread. Thanks.
| [reply] [d/l] [select] |
|
|
|
Most style guides I work under ask for the full package name of external functions
What an awful idea. Just being explicit about what you import from any module you use is a much better idea. @EXPORT is evil but @EXPORT_OK makes for easier-to-read/-write code and provides reasonable interface verification (at compile time, no less). demerphq already said all of this, but I just boggle at the sentence I quoted so I had to chime in against such insanity.
| [reply] |
|
|
| [reply] [d/l] |
|
use YAML; print Dump(...), but that requires actually installing YAML first.
You might try installing Data::Dump::Streamer (along with the DDS alias.) Then its just use DDS; Dump(...); :-) Its a Data::Dumper replacement (not drop in) which does a more or less breadth first dump of your data so its usually a lot easier to read, especially for cyclic and selfreferential data structures.
| [reply] [d/l] |
|
use YAML; print Dump(...), but that requires actually installing YAML first.
You might try installing Data::Dump::Streamer (along with the DDS alias.)
So, your suggestion to sfink's drawback of having to install a module is to install a module?
| [reply] |
|
Re: brian's Guide to Solving Any Perl Problem
by ff (Hermit) on Jul 25, 2004 at 05:34 UTC
|
The best debugger in the universe is print.
print STDERR "The value is [$value]\n";
To which I'd add, while not earthshaking or original, that I like using warn even more than print STDERR. Besides being shorter, the fact that it's different makes it easier to find such statements and comment out those lines when I'm through with them.
More particularly, I put my debugging 'warn' messages at the start of a line. Since most of my perl code has been indented a couple of tabs away from column 1, the fact that these statements are 'debug' type statements stands out. And since I might want to reuse the same debugging statements from time to time, rather than erase them when I'm done, I just comment them out when I'm "through" with them. This way, when I'm desparate later to know what's happening in some region, those previously written warn statements are there, waiting to be uncommented. And if I uncomment seven or eight of them (among the dozens/hundreds in my code :-), I can easily find them again to turn them off when I'm done with them by doing a vim search for them at the start of a line.
/^warn
Then repeat my search with n and repeat my 'uncomment' with a dot. Because these statements are at the start of a line, they can be found differently than the warn statements that are in the clear and are SUPPOSED to fire when triggered by real problems.)
I also find that including
use Carp qw(cluck);
early in my program and using
cluck
statements at the start of a line (a la warn) helps me figure out just how a particular subroutine got invoked. | [reply] [d/l] [select] |
|
| [reply] |
|
| [reply] |
|
Of course it's fine to save warn() for "real" error messages, but then the same could be said for only using print() for real output messages.
My problem, for which I'd welcome suggestions, is that I'm not familiar with how to use debug() in the midst of debugging a huge Tk-based application that I'm working on. The subroutines I am debugging get fired when I click one of the Tk buttons, and I know for sure that I can get at my warn() messages as above via my STDERR files. Out of ignorance, I'm just expecting use of debug() to be impractical.
| [reply] |
|
|
A most enlightening post, if I may say so, brian_d_foy.
I also used to use warn() until I realised that, when re-running Test::* based modules, it [the use of warn()] 'gets in the way' of true warnings - ever since when I, like you, define an additional sub to printf STDERR ... - thus the code behaves as I think it should whilst still generating debugging messages that don't cause test case failures.
A user level that continues to overstate my experience :-))
| [reply] [d/l] [select] |
Re: brian's Guide to Solving Any Perl Problem
by jkeenan1 (Deacon) on Jul 21, 2004 at 02:09 UTC
|
s/peice/piece/g
| [reply] [d/l] |
Re: brian's Guide to Solving Any Perl Problem
by BooK (Curate) on Jul 22, 2004 at 11:52 UTC
|
| [reply] |
|
Somebody? :)
I'm getting a lot of good comments here (I'm surprised really: not by the quality but the quantity), so I'll eventually roll them back into the other version along with credit to anyone who helped.
I should also list all transations in the main document too.
I could really use a Russian translation though. And maybe a Swedish Chef one.
--
brian d foy <bdfoy@cpan.org>
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by jeremyh (Beadle) on Sep 15, 2004 at 23:51 UTC
|
Have you watched The Daily Show with Jon Stewart?,
Several people commented along the lines of "take a break and do something else and it will come to you".
This has happened to me enough times that I really started to think about how/why it worked.
My theory is that it puts your mind into a different problem solving mode, similar to problem solving in the dream-like state, which I've also experienced. This seems to allow greater creativity, new approaches, and synthesis.
| [reply] |
|
I've learned to love my dry erase board at work. When the mental block is on full it sometimes helps to step back and diagram the problem showcasing both flow and\or expectation of how the code is intended to work. More often than not, if there is a problem in logic, it becomes apparent from the flow and if it is a choice of code function, the expectation becomes apparent. Dry erase makes it easy to edit and if all else fails, I guess sniffing the marker comes to mind.
Great article Brian.
| [reply] |
Re: brian's Guide to Solving Any Perl Problem
by fenLisesi (Priest) on Nov 24, 2006 at 11:56 UTC
|
| [reply] [d/l] |
Re: brian's Guide to Solving Any Perl Problem
by AntsPants (Novice) on Aug 09, 2007 at 08:26 UTC
|
I find going for a pee solves most of my problems. You think I'm joking?!! (forgot to login the first time doh!!) | [reply] |
Re: brian's Guide to Solving Any Perl Problem
by targetsmart (Curate) on Apr 01, 2009 at 11:33 UTC
|
Amazing text first of all, a ++ to it and all other good suggestions around it
now my part of contribution
If you want to do some changes in order make your (huge in number of lines of code)script working(on which you recently faced some problems during extending code or adding new functionality), before incorporating the new change in the original script try to write a small script(probably a perl one liner) and check whether your that small logic will work in the small script, they try applying in the original script
I use this method if I want to include a regular expressions in to my existing scripts(huge in size), and it is assured that it works correctly provide I check it simple program or one liner.
Vivek
-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
| [reply] |
Re: brian's Guide to Solving Any Perl Problem (perl version too old?)
by Anonymous Monk on Mar 14, 2013 at 00:20 UTC
|
$ perlver foo.pl
--------------------------------------
| file | explicit | syntax | external |
| -------------------------------------- |
| foo.pl | ~ | v5.10.0 | n/a |
| -------------------------------------- |
| Minimum explicit version : ~ |
| Minimum syntax version : v5.10.0 |
| Minimum version of perl : v5.10.0 |
--------------------------------------
$ perlver --blame foo.pl
------------------------------------------------------------
File : foo.pl
Line : 3
Char : 17
Rule : _perl_5010_operators
Version : 5.010
------------------------------------------------------------
~~
------------------------------------------------------------
$ cat foo.pl
my $foo = 6;
my @bar = ( 3,6, 9 );
print 1 if $foo ~~ @bar;
Then you can add use v5.10.0; or use 5.010000; to your foo.pl, and perl will do the version check
| [reply] [d/l] |
Re: brian's Guide to Solving Any Perl Problem
by pmonk4ever (Friar) on Sep 15, 2009 at 19:31 UTC
|
Brian,
Thank you for the excellent work you have created here, I just stumbled onto this by a comment from the ChatterBox!
Some of these items I was already following, however, several are new thoughts on old habits. And I thought I was the only one to have fallen into these traps!
Thank you for your wisdom. This is a node I shall have to link to.
pmonk4ever
"No trees were harmed in the creation of this comment. However, a rather large number of electrons were somewhat inconvenienced."
Update: This line is still broken: print STDERR "The value is ]$value]\n"; | [reply] [d/l] |
|
|