Well, I scanned through the other answers somewhat, but didn't really read them, and decided that it'd be good pratice to answer them, so here we go...
- Well, the most common one I use is -e -- for putting a short one-liner on the command-line. Almost as often, I use -l -- makes print append a "\n" automatically. (Somewhat annoyingly, -l does not effect printf.) Also, -M, which is shorthand for use, very useful with -MO=Deparse,-p. Less often, but still rather common, is -I, shorthand for putting a dir in PERL5LIB / @INC. (Somewhat different from use lib.) Also, -p and -n are sometimes useful -- they are shorthand for
while (<>)<code> loops, both with and without printing $_.</li>
<li>They give the sort of thing returned by the variable expression -
+- scalar, list, or hashy list. (Note that the obvious -- they are pa
+rt of the name, giving the type of variable -- is slightly wrong in p
+erl5, but correct for perl6. The difference is <code>$foo
- Modules and subroutines, including in some cases OO. Also, POD and comments. Also, refs, and in purticular code refs.
- This is always a difficult question, for any language. Somewhat easier to answer is "what are characteristics of a project that make it poorly suited to Perl". One is if the project is already largely complete in another language, and the completed part is not easily wrappable in a library. Another is if the people who should be working on the project do not know perl, and the other languages they know are decently suited to the task -- even if perl is better for the project, it may not be worth the learning curve for this project.
- I program in Perl because it lets me focus on the bits of the problem that I wish to. I don't have to manually handle memory management; the runtime does that for me if I follow a few rules, which I very rarely have reason to wish to not follow. There are many free and high-quality libraries available -- I don't have to code my own XML parser, or my own database interface. The perl community is highly supportive -- if I want help and advice, I know where I can go to get it quickly, and with a low occourance of bad advice. Oh, and there is very little that is impossible to do in perl, and when there is such a thing, I can program just a bit in C, and the rest in perl, quite easily, by using Inline.
- my uses lexical scoping: the variable is visible from the statement after the my until the end of the block that encloses the my statement. This means that you know where the variable will and won't be visible from just a glance at the code -- a great improvement from dynamic scoping, which is what local uses. In dynamic scoping, the variable is visible from the line following the local statement to the end of the enclosing block, and any code called from there, and any code called from code called from there, etc. This means that there's no telling where it will show up, and where it can be modified, encourging code that is difficult to keep straight in your head, and where modifications to one piece of code may change the behavior of other code that, at first glance, appears completely unrelated. Additionally, dynamicly scoped variables are slightly slower to access.
- Use takes place at compile time, require takes place at runtime. Use automatically calls the sub named import in the module being used (unless the use statement is followed by a pair of empty parens), require does not call the import sub. Because of this, if you expect the module to do setup at use time, or export semantics (including subroutines and pragmatic behaviors), then use "use". If you want it to be effected by the flow of the program, use require. Otherwise, it's a matter of taste -- most people use use, mostly because it's slightly shorter.
- I'd have to go with strict. It makes me more efficent by catching many of my errors early, and making them easy to find. Not only that, but it encourages me to think about my scoping, leading me to produce better code. I use strict in almost every piece of perl I write, and when I don't, I often end up regretting it.
- A hash is a mapping from string keys to scalar values. The mapping is unique and unordered. Dispite this rather humble defintion, it has an amazing power to create powerful and elegant code; easy-to-use hashes are one of the simplest reason that Perl is such a wonderful language. Many other languages have hashes, but they tend to be implemented as a class of object, which means that the syntax required to access them gets in the way of what you're actually interested in when reading and writing code -- the problem you are attempting to slove.
- Well, none of those problems are purticularly ammenable to writing simple regexes that match everything they should and nothing they should not. Fortunately, there is a module, Regexp::Common, that already has regexes for matching IPs and email addresses. The problem with IPs is that they require numeric operations to match correctly; not all three-digit numbers are valid octets. Not only that, but 10.1 is a valid IP address -- it is an uncommonly used, but quite legal, shorthand for 10.0.0.1. As for email addresses, while ^/[^ ]@[a-zA-Z0-9-.]+$/ will match most email addresses, it will not match all email addresses. It will not match the forms that include comments, nor will it match the @-less form (IE ones that use the default domain name of the server). It will, however, catch many things that are not valid email addresses -- those that include a domain name that does not actually exist, for example. (Many other common regexes for email addresses will fail more -- for example, many people do not realize that + is both a valid character for the username part, and a rather common one. Many people do not realize that some addresses at registrars have names like noc@cc, with no . in the domain-name part.) city-state-zip is complex because the comma is sometimes missing between city and state (in fact, the USPS prefers that it not be there), and the state may be written as a two-character code, as the correct state name, or as an incorrect-but-common abbreviation. The ZIP code may be not present, 5 digits, or 5+4. For that matter, attempting to match against a regex will miss mailing addresses from outside of the US, fustrating users and loosing customers.
- -w enables warnings globally for the perl interpreter. It can be used for code that needs to maintain compatability with 5.005 and older perls, but for newer code, use warnings is better, because it will not enable warnings in parts of the program that are not designed to be run with them enabled. Strict I mentioned previously, as my favorite module. It disables constructs that make for unmantaintable code and increased time spent tracing avoidable errors: implicitly global variables, bareword strings, and symbolic references. Of course, individual strictures can be turned off for the portions of code that need them -- most useful for symbolic refs in the very limited circumstances where they are useful. -T is taint mode. It will catch certian classes of security issues when dealing with untrusted user data. However, -T is no replacement for thinking about these issues explicitly -- it will allow some types of things that should not be allowed, and will disallow some things that are perfectly safe.
- There is no difference between for and foreach; they are simply alternate ways of writing the same thing. Exec and system differ in that exec replaces your code with some other executable, whereas system creates a sepperate process. Exec will never return (unless the exec failed); system will return.
- That depends on what you mean by "go". If I need perl documentation, perldoc, perldoc -f, man, perldoc.perl.org, or search.cpan.org, depending largely on my current environment and mood. If I need to ask other humans a question, then perlmonks.org -- either Seekers of Perl Wisdom for written help, or the chatterbox for "spoken" help.
- I regularly use Finance::Bank::Norisbank -- in fact, I use it exactly every two hours, from a cron job; it keeps track of activity on my bank account. I write code that uses HTML::TreeBuilder, LWP::Simple, and XML::Simple quite often, essensially whenever I want to do a repetitive task involving the web. I can often write code that preforms a repetitive task faster then doing it myself, and it is almost always more interesting to do so.
- Generally, with IO::Open->new($filename, ">") or die "Couldn't open $filename for writing: $!";. In some circumstances, of course, death is not the right thing to do when the file can't be opened, or I wish to append with >> rather then overwrite with >, or I wish to open the file in utf8 mode with ">:utf8".
- $string =~ s/a/b/g
- my $count = $string =~ s/a/b/g. Sometimes, I use tr/// instead of s///; tr is more convient when there is a mapping of multiple chars to multiple chars, and the mapping is more easily expressed explicitly then via code.
- I already answered this question
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link or
or How to display code and escape characters
are good places to start.