If, when you look at the documentation for a core-builtin, like so:
$ perldoc -f system
you get some funny characters in the output (long dashes, 'smart' quotes, etc) - and you wish to remove them (to make copy-pasting of code easier,) then simply:
$ perldoc -tf system
The -t flag avoids any fancy formatting and just outputs plain text.
Just by using the utf8 pragma in your Perl, you can do things like this:
use Modern::Perl;
use utf8;
my $天 = 'sky!';
say $天;
for my $否 (split(/ /, "no no NO no! NO!")) {
say $否;
}
Seeing escape codes when you run perldoc?
Set your $PAGER environment variable up correctly:
export PAGER="less -R"
... between two Perlers today:
chromatic:
Some days the jerks and bugs and workarounds and fame-chasing pundits make me want to leave technology as a profession.
Larry Wall:
If you do leave, you will find jerks and bugs and workarounds and fame-chasing pundits in most other professions too.
chromatic
At least real life hides its backwards compatibility misfeatures in DNA where I can't get at it.
Haha :-)
I have set up this mapping:
nnoremap <silent> <F9> :%! perltidy -q -pbp<CR>
... now I just hit F9 and I'm set.
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.
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!
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:
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.
A note on how to start/setup your Perl module:
h2xs -XA -n Your::Module
... this creates a good skeleton.
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.
Django Python 960.gs Git Vim NetBSD Nginx
The author is a software engineer living in Australia. He sux at guitar, loves camping, doesn't like cake, does like coffee and is a lazy home brewer.
Help
Latest entries
*BSD Agile Apache Apple Athletics Beer Best-Practice Censorship Comedy Cool Crosswords Deployment Django English Exim Firefox Git Hardcore Health Interface irssi Javascript Jira Languages Linux Makefile Markdown Mathematics Mobile Broadband MySQL NetBSD nginx Nokia OSX Perl Photo Privacy Python Rant Requirements rsync Ruby Shell Slackware SQL SQLite SSH Standards Subversion Testing ThisBlog Vim VMWare (Fusion) VPN WDTEM X Yum zsh
Perldoc Output
Yum
Possum
Git's Index
Jira Project Keys
The Coffee Shop
Git GUI
It is more important...
Questioning Unix (and Other) File Times
The Frog King Photo
Rain Cloud Photo
rsync
Timezone
utf8 in your Perl
Theatre Ceiling Photo
Some problems are so complex...
Colours in your PAGER
zsh vared
zsh magic-equals and double-star
Funny Tweets
ChoppingBoard, Project365, RageQuit