good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
jakobiby jakobi (Pilgrim) |
on Sep 18, 2009 at 18:52 UTC ( [id://796180]=user: print w/replies, xml ) | Need Help?? |
( mbox outbox | node allowed html shortlinks | cb last hour im2 de/cloak )
grep(/perl/i,@Bio)Wrt computers, my main interest is most things Unix. As for perlmonks, my github archive may contain some stuff of interest, a subset of which is also on cpan and freshmeat. I started out with perl3, rexx and g/awk, besides Assembler, C and the usual UNIX environment. But it took a royally messed up IRIX awk/nawk migration idiocy to make me leave the awkward ways of the heresy and develop an enlightened interest in Perl. Some of my tastes are still affected by that trauma: I must confess to having a dislike for perl5 OO due to the lack of the one official default style to bind them all (see e.g. Re: use common::sense; for related issues), as well as a preference for standalone scripts (let me just copy this script to those servers to do that...), which results in a rather high threshold for when to switch to using or writing modules. Furthermore, while I've overcome awk long ago, I still suffer from a craving for long sequences of /awkish line-noise/. PerlsPM Nodes and Code on PM I Intend to Keep Current{N2S: do mark&color the node pointers for these also in the FAQlets below and to pm_back}
If it's not PM-specific, you'll find most of my public stuff in the archive(s?) below jakobi.github.com. With currently 90+%, that includes way too much Perl. Bookmarks from meta-PM to pure Perl
Rants and Major GoofsAVOID AT ALL COST: <> and perl -eI really cannot believe my eyes: This one turns Perl into a single major security issue that needs to be disallowed to anyone in a professional setting, users and developers alike: Don't ever use <> or perl -e: magic-diamond <> behavior -- WHAT?! and executing filenames as shell exploits even with the most trivial of filters. Which for most settings probably ought to translate into avoid Perl itself. And darn it, correctly so. What's worse, there are actually people insisting on keeping the security hole unplugged. Note that -i.bak renames first and seems to use the 3 argument form, so it escapes from being attacked. Note that using <> ONLY with STDIN isn't affected due to lack of filenames... . Some more bandaids are code replication, explicit use of <STDIN>, tainting with -T, or @ARGV mangling with e.g. ARGV::readonly, all of which with additional semantic changes and side-effects of their own.And no, the issue isn't the well-known magic insecure 2-argument open (surprisingly, the 1-argument version is secure), as this is but the tiny and mostly-harmless core of the real problem. It's its unexpexted use in <> that makes an insecure mess of easy, idiomatic perl uses: One of the shortest possible ways to loose control of your servers: perl -0pe: Should we start to advertise awk-oneliners now, given that most Perl oneliners are too dangerous for a quick suggestion without both bandaids (larger than the original oneliner by a line or ten) and a twenty-hour lecture series on security issues? Would you trust someone of little Perl history to only ever use your shown oneliner with safe STDIN and never with unsafe filename arguments? Makes you wonder. And decide against teaching Perl to collegues. Another goof of that order of magnitude and Perl won't have even a tatter of credibility left. Did I miss an official change of Perl's motto to Make easy things unsafe and hard things worse? Increasing problems and creating new problems wasn't what Perl was about. Now on to the damage that was done today, and on to the grep for the fallout. Just a few MB to check. (Damn right, I'm pissed. And wondering if even Perl6 is going to be capable of outliving this kind of damage). Perfect advertisement for Perl. If you warn against using Perl for small stuff. To be checked: are Perl6 one-liners safer? If so, this _might_ work for non-Perl-collegue-safe quick commandline hacks, provided the hack won't compile in Perl5 (or how would you avoid accidental but-I-only-changed..., just-like-you've-shown-me fatalities?). Maybe I should just look at Haskell ([id://520826|tasty...) or OCAML for new stuff. Well written ML is a thing of beauty to behold. Non-Perl Pearls
Perl FAQletsAs laziness is one of the Perl user's virtues to aspire to, I hope that I can reuse these faqlets as a resource in future answers. {N2S: do mark&color the node pointers for owned nodes to be kept uptodate: here & add them to pm_back & the list of updated non-home nodes above} Common Questions and ClassicsKeep Scott McMahan's quote in mind when meditating on the fine points of Perl functions: Perl is the portable distillation of the UNIX philosophy. If in doubt, search the margins for the proof in Unix section 2 and 3 man pages (BSD,Linux, Solaris) as well as Posix in addition to perldoc -f. On cleverness, there's a real nice Kernighan quote: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. On virtues, misconceptions and Gödel. Also meditate on the Unmentionable Virtue: Paranoia. Keywords to read up onNote that the links just provide an example thread for the topic, not necessarily a meditation on the topic or the authorative one and only correct answer... . Drop me a line if you want to suggest a better discussion thread or link.
Debugging and OptimizationSee Debugging and Optimization. I still hope for a single public node to point monks to; failing that I'll place an augmented copy of this node here, hopefully finding also the RFC threads for all of its links. A tutorial w/o RFC thread is about 70%-completed tutorial crossed with a trap and a time sink. We should do better than that, but still without drowning seekers in a vast ocean of widely dissipated partially outdated scraps of help. Especially start-off tutorials shouldn't assume seekers to be already grand masters of swimming and searching, have them train in a smaller inland lake's probably the better approach. Don't be afraid of the foundations and the layers below Perl: For now let's just say to always first check CPAN and the module documentation, FAQs. After that use Unix basics like strace/truss or locate/find to take a peek at syscalls being used or the module source. To read up on the actual syscalls and their arguments e.g. for wait/waitpid (syscalls are more or less lightly by Perl and libc - cf. flock): grep your actual kernel's authorative definitions in /usr/include. If you can read Perl and non-trivial Perl REGEX, a mere overgrown macro-assembler like C shouldn't challenge you. And much of Perl including many of the operators _is_ the same as in C. Examples include:
Windows Survival Using Perl and Unix CommandsFor generic Unix app ports to Windows or accessing Unix from Windows, check e.g. Freshmeat with suitable keywords. Be certain to include windows versions of firefox, a vnc client and putty in your hunt-list.
Notes of a new PerlMonk / Meta - TopicsWhile I've used Perl for ages, I only recently joined PM when being stumped by a CPAN cultural issue I'm still wondering about. This section isn't about Perl, but rather about Perlmonks.org itself. It lists both my observations as well as hard-to-find info-nuggets not listed in the main FAQs (or at least lacking the emphasis necessary to register late at night). PM-newbie experience log
PM-newbie - the missing memesConfiguration settings and other tips
A visit to the MonasteryOn "stupid" Questions and hidden GemsStupid questions - assuming you stick to thread to to reply to questions and had a go at the documentation - don't really exist. Stupidly posed questions do exist: lack of use strict; use warnings;; horrible formatting of code or node; lack of input; lack of output; lack of stating what you've already read or attempted; providing code that is overly long or just does neither parse nor execute. But just about any question might result in answers that are true gems in their own right.Thus there's no reason to NOT ask your system or Perl an interesting question (see above), nor is there any reason to NOT ask your fellow monks. If wondering whether a question is a troll, maybe wait a bit with a reply. But then, if the topic can be misdirected into more interesting waters, I'd suggest to leave some food as offering for trolls and fellow monks (do check out the link to audreyt's border-collie-style handling of hapless trolls in the 2nd PS). Participation in Common Monk Activity is Obligatoryor is it? Anyway, you know that you spend too much time on PM when you <insert the usual>: JAPH01> perl -MPOSIX -e 'sub _{($.,$/)=@_;eval"\$\\.=sprintf\"\%s\",\"".(grep{s/\S/do{(ord($&)<42+4*2**0.42)?chr((42\/3+1)<<3):$&}/ge,42}grep{s%(?!$)%do{$//=2;"\\\/".(($/=~s/\.\S*//)?ceil sqrt 42:int sqrt 42)}%ge,42}sprintf("%x",$.))[0]." \""};@_=(42292,14,32458834,72,58668,5,8469330,32);while(@_){_@_;@_=@_[2..$#_]};print'|tr UNIX~ REWOP PM-related Shortcuts (private)Bookmarks (private where-did-I-see-that-avoidance section)
Not yet sorted PM Bookmarksshould go here on being moved from the end of jakobi's scratchpad to read: some example threads are listed with each topic http://perldoc.perl.org/perlfaq4.html#What-is-the-difference-between-a-list-and-an-array%3fincomplete as it probably is, google seems to see the whole thread pages while supersearch sees nodes separately. http://www.tinymicros.com/ptav/ - by date, but dynamics like search is mostly fail |
|