Vim & Vision

You searched for articles tagged with Perl.

[ #173 ] perltidy.rc from Best Practices Permalink

Perl Added less than a year ago and last edited less than a year ago

I just found out that if you call perltidy like so:

perltidy -pbp

... it will implement all recommended formatting options as specified in the Perl Best Practices book.

So ignore the initial version of this post, which was:

According to Perl Best Practices, your perltidy.rc file should look like this:

-l=78   # Max line width is 78 cols
-i=4    # Indent level is 4 cols
-ci=4   # Continuation indent is 4 cols
-st     # Output to STDOUT
-se     # Errors to STDERR
-vt=2   # Maximal vertical tightness
-cti=0  # No extra indentation for closing brackets
-pt=1   # Medium parenthesis tightness
-bt=1   # Medium brace tightness
-sbt=1  # Medium square bracket tightness
-bbt=1  # Medium block brace tightness
-nsfs   # No space before semicolons
-nolq   # Don't outdent long quoted strings
-wbb="% + - * / x != == >= <= =~ !~ < > | & >= < = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
# Break before all operators

I believe reprinting this is a service to the Perl coding community - I hope nobody gets angry, especially since I have linked to the book's site, highly recommend it, and have found this perltidy.rc posted on Perl Monks.

[ #164 ] Blurring the Line between Modules and Scripts Permalink

Perl, Python Added less than a year ago and last edited less than a year ago

Perl modules are named .pm and Perl scripts are .pl. You are supposed to keep your packages in your .pm and your scripts that you run from the command line in your .pl. However - you can create a (number of) package(s) within a .pl... and you can also run a .pm from the command line.

If you use a module then your module must be a .pm. If you require a module it can have any extension.

You could also have a script that is simply named yourapp without any file extension, which is useful for when you want to include your modules and script in the one file - presumably for easier distribution.

Keeping your modules as .pms and your scripts as .pls is nice for clarity - so people know by looking at a directory listing which file is which.

I've found that I sometimes want to treat one like the other, so that's what today's trick is all about.

First some background about how Python handles this.

Python files are just .pys, and if they contain a class or functions but also should be run by themselves like a script, then this idiom is used:

class Yours:
    def something:
        ... code ...

def main:
    ... code ...

if __name__ == "__main__":
    main()

We can emulate this in Perl like so:

package Yours;

sub something {
    ... code ...
}

package main;

sub main {
    ... code ...
}

&main if ! caller();

1;

This file could have any extension. If it is run as a script then main will be run - but if it is used or required then it won't be!

[ #159 ] Simple Deployment with a Makefile Permalink

Deployment, Makefile, Perl Added less than a year ago

I have used Capistrano to deploy a complex web site before, but I have recently looked to Makefiles for a simple solution.

I will describe the project and situation where I have successfully used a Makefile to deploy a static website - this situation does not require complex tasks that capistrano would be able to handle - and certainly can't do rollbacks. If you are deploying something complex then please use a proper deployment tool.

The project builds an HTML website using a yaml config file (config.yaml), a bunch of chapters written in markdown (input/*.md), templates written in Dotiac::DTL (template/*.html) and a Perl script build.pl.

Running build.pl builds HTML files in an output directory (output/*.html) using the aforementioned parts.

Some targets in our Makefile include:

Making the output - make all
Creating an archive of the output - make archive
Deploying the archive to a remote host - make deploy

Our Makefile looks like this:

ARCHIVENAME=$(shell grep Title config.yaml | sed -e 's/ *Title: //;s/ //g;')
DATESTAMP=$(shell date '+%Y%m%d')
ARCHIVEDIR=archive
OUTPUTDIR=output
HOST=targethost.com
HOSTCOPYDIR=/home/www/docroot
HOSTTARGETDIR=/home/www/docroot/mysite

all: clean input output
    perl build.pl

archive: archivedir
    cd ${OUTPUTDIR} && tar -cjf ../${ARCHIVEDIR}/${ARCHIVENAME}-${DATESTAMP}.tar.bz .

deploy: all archive
    scp ${ARCHIVEDIR}/${ARCHIVENAME}-${DATESTAMP}.tar.bz ${HOST}:${HOSTCOPYDIR}
    ssh ${HOST} mkdir -p ${HOSTTARGETDIR}
    ssh ${HOST} tar -xjvf ${HOSTCOPYDIR}/${ARCHIVENAME}-${DATESTAMP}.tar.bz -C ${HOSTTARGETDIR}

archivedir:
    mkdir -p ${ARCHIVEDIR}

clean:
    rm -rf ${OUTPUTDIR}
    rm -rf ${ARCHIVEDIR}

output:
    mkdir ${OUTPUTDIR}

Now whenever I make a change to an input markdown file I can just run make deploy and the production site will get updated.

[ #154 ] Perl - Creating Modules for CPAN Permalink

Perl Added less than a year ago

A note on how to start/setup your Perl module:

h2xs -XA -n Your::Module

... this creates a good skeleton.

[ #151 ] Capture STDOUT in Perl Tests Permalink

Perl, Testing Added less than a year ago

If you are unlucky enough to be working with a sub that literally prints things out, but you would like to test what it is printing, you can intercept the prints using this lovely library:

use IO::CaptureOutput qw(capture);

my ($stdout, $stderr);
capture(sub { sub_that_prints_things($arg) }, \$stdout, \$stderr);

... now you've captured all the printed info from that sub into the two scalars!

This is very handy for testing.

[ #143 ] Examine Source of any Perl Module in your Path Permalink

Perl, Shell Added less than a year ago

Perldoc helps out:

$ less `perldoc -l strict`

... gives us a look at strict.pm.

[ #142 ] perltidyrc Permalink

Perl Added less than a year ago and last edited less than a year ago

Here is my .perltidyrc for future reference:

-i=4
-nsbl
-pt=2
-bar
-nolq
-msc=1

[ #141 ] Using perltidy from vim Permalink

Vim, Perl Added less than a year ago

Make sure your .perltidyrc is setup, then just:

:%!perltidy -q

... and voilà - tidy source.

[ #134 ] Manually Setting Vim Syntax Permalink

Perl, Vim Added less than a year ago

If you are editing a Perl script but the script name doesn't have a .pl extension and no hashbang line, your syntax highlighting will not work.

To manually set the syntax highlighting do this:

:set syntax=perl

[ #131 ] What is Perl? Permalink

English, Perl, Rant Added less than a year ago and last edited less than a year ago

From PerlFAQ1:

Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter.

Perl is a language specification. Languages (well, grammars) should be able to be expressed in BNF or EBNF or other formal notations (if you are a perl expert and have just registered alarm bells, refer to note at bottom of post.) If someone likes Perl, it might be because they like the expressiveness of the syntax. Perl can exist without any interpreter or community or libraries. Perl can exist on paper only.

perl is an application or program that runs (interprets) languages written in Perl. There is one major implementation of perl (pre-Perl 6 that is), but there is nothing stopping you from writing your own version of perl right now (except time and incredible effort, again, please see the note at bottom of post) - although you'd call it something else wouldn't you? If someone says they don't like perl, they might be talking about how the internals of the perl application are filled with deep voodoo - that the C that describes and implements perl is hard to follow and hard to extend. Or they might be complaining about the command-line flags that perl recognises. perl requires Perl to exist. If perl was interpreting a language that was not Perl, then it would not be called perl.

~Perl~ is a term I just made up. It describes the combination of Perl, perl, libraries included with the standard distribution of perl, CPAN, the Perl community, Perl books, perl books, etc. If someone says they don't like "Perl" because of something that annoys them with CPAN or perlmonks or even a library that is distributed with perl, then they are talking about ~Perl~. If CPAN didn't exist, Perl and perl could still exist!

Am I always so careful as to use the correct spelling of Perl or perl? No, I'm sure I've stuffed up a lot, including in this blog, but I've been thinking about the distinction lately so I thought I'd post on it. Perl would be useless without perl. perl would be almost useless without ~Perl~. However, if you removed all that is ~Perl~ except for Perl and perl, people would create a new ~Perl~. New libraries, new distributions, new websites etc would spring up, made possible by having a working perl. It would likely be a slightly different version of ~Perl~ than before, and that's OK.

Similarly you can like Python, hate python but love ~Python~. Actually, it turns out that there are at least three major python implementations: the so called "cpython" (the main python app, from python.org); "Iron Python" (a .NET implementation) and jython (written in Java.)

Recently, so I'm led to believe, the performance of java has improved considerably. I remember when I was at uni I would say that I hated Java because of its poor performance. I was wrong to say that, I should have said I hated java (or javac, etc.) Java is the language, and is not what I was talking about. Incidentally I don't like Java either, because I think it is too verbose and requires too much boilerplate. But that's just my opinion!

Is it ridiculous to make these distinctions? I don't think so. Annoying in polite conversation? Almost certainly. I think it's interesting to think of the difference especially with different versions of Python interpreters/compilers (see above) and Perl 6 interpreters/compilers around the place (Rakudo and Pugs for example.) You could say that you hated Pugs, loved Rakudo, loved Perl6 but were disillusioned with ~Perl6~.

Notes:

1. Do I honesty believe anyone will start using the term "~Perl~"? Of course not, I just had to type it differently for the purpose of my rant! It's even impossible to tell just by listening as to whether someone hates Perl or perl or ~Perl~ - but you might try asking them whether they are talking about the language, the executable or the community. At least that way they will be forced to back up their opinion intelligently.

2. Sometimes I see reference to PERL. PERL is a mythical creature of the past, associated with spaghetti CGI scripts from 1997, or with people who don't program much. I don't really think PERL ever existed, and if it did let's pretend it didn't.

3. Can Perl actually be expressed in BNF? Well no, it can't be expressed in BNF because it is not a context-free grammar. This article will show you some examples of very ambiguous Perl statements, and tell you that only perl can interpret them. By that it means that there is lookahead code and certain resulting decisions in perl that are not obvious when looking at the Perl grammar. perl is in fact the one authoritative source on how these ambiguous, context-based examples should execute. This fact might make you think that Perl and perl are tied more closely together than I have made out, and in reality this is very true. But at the end of the day perl is just a program that implements algorithms, like any other program! Even if these algorithms are not documented well, you could still - given enough time and intelligence - write them down in some kind of pseudocode (or even convert them to another programming language.) The logic in this pseudocode in combination with other formal grammar specifications would describe a Perl on paper. This Perl would then be implementable by any number of perls.

Older Posts ... Newer Posts

Colophon

Django Python 960.gs Git Vim NetBSD Nginx

The Author

This is the blog of Brad Willis, a software engineer living in Brisbane.

Links

ChoppingBoard, DaveMisc, Project365, RageQuit