Totally annoying.  A simple Perl script fixed it.  Don’t know why they didn’t put it in their samples, though.

#!/usr/bin/perl

use strict;
use warnings;

=head1 NAME p4_check_passwd

Called with the user name on the command line and the password on standard
input, this program returns a success or failure depending on that password's
correctness.

Uses getpwnam to do so, and must run as root on in shadow group to access
/etc/shadow and password data.

This should be configured in p4 triggers as an auth-check trigger:

Triggers:
unixpw auth-check auth "/home/perforce/bin/p4_check_passwd.pl %user%"

This uses the crypt system call, which should handle any variants of encryption
in your password file. It also uses the getpwnam() function to access
the password data, so should be able to access data from NIS or other
configured password system.

=cut

# Perforce wants all messages on stdout. Guarantee that.
open(STDERR, ">&STDOUT") or die "Can't redirect to stdout\n";

# Get the user name
my $username = shift;
die "Need user name on command line\n" unless $username;

# Get the password
my $password = <STDIN>;
chomp $password;

# Get username and password from the system
my ($name, $passwd) = getpwnam($username);

die "Can't log in as $username\n" unless ($name and $username eq $name);
die "Can't access encrypted passwords\n" if(not defined $passwd or $passwd eq ''
or $passwd eq 'x');

# Check password and return correct exit code or die.
if(crypt($password, $passwd) eq $passwd) {
	exit 0; # Silent, successful exit worked!
} else {
	die "Can't log in as $username\n";
}

Works for me, anyway.

Step 1: Install Foswiki

Follow the installation instructions.  Using CGI is easiest to set up, if you watch the gotcha I found with running bin/configure.  FCGI is much faster, and works well once you install the extension, and if your host supports it.  (Mine does!)

I have had a little trouble getting the Apache config right, and have had to make several changes to get it working in my webserver configuration.  Make sure the virtual host is correct (not the default *), that the logs are as you want them, and to add a redirect for / to /foswiki/ if you want that.

Step 2: Configure Foswiki

Use the bin/configure script to configure Foswiki.  Mostly this is paths and mail.  Add the FastCGI if you want to use that.

Step 3: Add Admin Users

I like to create a user (or users) for administration and put them in the AdminGroup so they have full rights to everything.  This is easier than using the special admin user.  I like to create a “FirstnameAdmin” user – I’m LouAdmin, usually – for each administrator.  Get the admin to create them and then use the magic ‘admin’ user to add them to the AdminGroup.

Step 4: Add Game Groups

For each game, you’ll want two groups.  GamePlayers and GameGMs.  Create them, using tools in Main/WikiGroups

Step 5: Add Users

Have the GM(s) and player(s) create accounts.  Add them appropriately to the GM and Player groups for each game.  The GMs does not have to be in the player group.

Step 6: Add Webs

Create a Web for GamePlayers and GameGMs.  (System/ManagingWebs).  Then, set each of those to be limited to the the correct groups.  Go to the WebPreferences setting for each web (GamePlayers/WebPreferences, for example) and update ALLOWWEBVIEW to the appropriate groups.  The Player web should have the players and the GMs, and the GMs should have only the GMs.

The GM web should look something like this:

• Set DENYWEBVIEW =
• Set ALLOWWEBVIEW = %USERSWEB%.GameGMsGroup, %USERSWEB%.AdminGroup
• Set DENYWEBCHANGE =
• Set ALLOWWEBCHANGE =
• Set DENYWEBRENAME =
• Set ALLOWWEBRENAME =

The Players web is the same, but includes the players in ALLOWWEBVIEW:

• Set ALLOWWEBVIEW = %USERSWEB%.GameGMsGroup, %USERSWEB%.GamePlayersGroup, %USERSWEB%.AdminGroup

In this modern age, where many (if not all) of the people at my gaming table have laptops or tablets, the use of a Wiki should be perfect.  However, many wikis have a strong feeling of “The Wiki Way”, which says everyone should be able to see and edit everything so that the experience and knowledge of everyone can be gathered and stored.

There’s at least two problems with this for a gaming Wiki.  First, the gaming Wiki’s probably on the Internet, where “anyone can edit” translates into “instantly defaced by spammers”.  That’s not ever good, and it seems to be ignored by many of the Wiki packages.

The second problem is that the GM needs a private place on the Wiki to conspire against the players.  If there’s more than one GM collaborating, they need to share information.  The players need to be kept out, so the things there can be a surprise when the game plays out.

It’s great if the players have a place to put their collective notes and information as well.  Some GMs want access to those, and some won’t.  Some will think these should be hidden to only players in the game, and some won’t.  (If the player characters are doing anything salacious or gaming anything subversive, it is perhaps best not to have those on Google.)

Enter Foswiki.  Foswiki allows access control by groups.  The next articles will detail how to set up Foswiki for RPG use.

When you install Foswiki, the installaiton guide sends you to an Apache Config File Generator. One of the options is to use cgi, or Fast CGI. Since I’ve used Fast CGI before and I know it works on my server, I selected that.

I got the configure program running, but the wiki would only 404.

I dug in and discovered the FastCGI configuration uses a foswiki.fcgi script, which wasn’t anywhere in my archive.

There’s a reason: It’s an extension you have to install. Foswiki dosen’t ship with FastCGI support.

You can install it through Configure; go to Extensions, click the Find and Install Extensions button, then install FastCGIEngineContrib.

A kind user there, gac410, knew this and got me straightened right out right away. Thanks again, gac!

Naturally, I turned this on.

Then I tried to run the “configure” script. It wouldn’t run, telling me I needed to run configure.

The short-url change aliases / to bin/view. That includes ‘configure’.

In short, don’t use the Short URL option until you’re done with configure, or turn it off to do so.

Commenting out the three lines in the Apache config is enough to turn it off briefly to run configure.

We couldn’t do it.  After a second look, I still can’t do it.  Not for all cases, anyway.

perlsub says lists a prototype of (*;$) for open, and discusses being careful not to override open by accident.  It also suggests prototype can show the prototypes for overridable items.

prototype ‘CORE::open’ returns “*;$@”, which is interesting, but not a match for perlsub.  ”*;$@” lets the function get called, though, and matches all the things open has to do.

I wrote a really simple wrapper for open:

 use Data::Dumper;

sub open(*;$@) {

    say Dumper(\@_);

}

I wrote a function to call it a couple of ways:

say "test 1:";

open (FH, '>file.txt') or die "Can't >file.txt: $!";

close FH;

say "test 2:";

open (FH, '>', 'file.txt') or die "Can't > file.txt: $!";

close FH;

say "test 3:";

open (my $fh, '>', 'file.txt') or die "Can't my > file.txt: $!";

close $fh;

Now I can see what those look like:

test 1:

$VAR1 = [

     'FH',

     '>file.txt'

 ];

test 2:

$VAR1 = [

     'FH',

     '>',

     'file.txt'

 ];

test 3:

$VAR1 = [

     undef,

     '>',

     'file.txt'

 ];

Okay.  The two calls with typeglobs get the name of the glob.  I can work with that.

The call with a lexical, though, gets the value.  Where/how do I return the handle?

I messed around some more, and when using lexicals, a Perl open() function is called with the value of the lexical, not with any way to identify the variable itself.  I can’t figure out how to get the variable to pass to CORE::open, or to return something into it.

And there I’m stumped.  Is it possible that the docs in perlsub are from the 5.5 days and don’t work since Perl 5.6 introduced lexicals as file handles?  Or am I missing something?

I could go dig in to CPAN and see if any other modules do this right.  How does Safe.pm do it?  Can it be done in an XS module but not in Perl?

Back to useful work instead of banging my head against this.

I’d been looking for a way to manage having multiple Perl installations on my system.  Ruby has something called the Ruby Version Manager which makes this really straightforward, and I figured there had to be something like it for Perl.  I hadn’t looked much, but what I had didn’t get me anywhere.  The Preface for Modern Perl mentioned it in passing.  The tool is called App::perlbrew and allows you to easily switch from one Perl to another and can help manage those Perl installations.

Combine that with local::lib so you can have your own installed modules, and you’ve almost got rvm.  The ability to have named module sets and turn them on and off at will is missing.  If it’s important, the two could be combined into a complete Perl environment management tool… but I don’t know if it is important.  A per-project Perl with modules installed might be enough.

One useful tool mentioned in Modern Perl is the Perl module Modern::Perl, also by chromatic.  It’s a helper to take some of the boilerplate that a modern Perl program should put in every program and module and condense it to one easy to read, clearer line of code.  It isn’t a big deal, but is nice.  (CPAN, as usual was full of similar things, but I didn’t think they were as well thought.)  I had heard of Modern::Perl because I’d been following chromatic’s blog.

The module I thought was really neat but hadn’t heard of was Task::Kensho.  This is part of the work of a group of folks who are trying to build an “Enlightened Perl” and is mostly references to other modules.  The module list includes some big stuff I’d run into – Moose, DBIx::Class – but also included a lot of just generally useful stuff that I’m sure will be handy.  There was also some things that were not critical but neat, like Smart::Comments.  There’s a bunch of stuff on that list I’ve been Meaning To Look At but haven’t gotten around to yet, like Devel::REPL.

The secret is to use links like this:  http://search.cpan.org/perldoc?Task%3A%3AKensho

The %3A are the URI encoding of a : so this goes to http://search.cpan.org/perldoc and searches for the module name automatically.  Neat.

Not only is it released, but chromatic has graciously made the book available  for download as PDF.  His publisher has it as both letter-sized and A4 sized formats for print.  It’s released under one of the Creative Commons (by-nc-nd) licenses so you can use it, share it, and distribute it freely and widely.  The blog announcement mentioned above encourages you to do so.

I’ve taken the time to give the book a first read, and I can only say that I’m impressed.  According to the blog posts, the book was produced in POD which was stored in a public Git repository for constant feedback and refinement from members of the community.  That’s really slick, and the content of the book shows how much work went into it.

The book does some things differently than other Perl books I’ve read, and I approve.  The preface starts of by giving the requirements for running the sample code from the book.  That includes Perl of no later than 5.10.1, and “use strict” and “use warnings”.  There is no example of trying to write code that works in Perl 5.6 or is just like the other things you’ve seen before .

It begins with some interesting sections discussing the philosophy of Perl, and where the community lives and how to find them.  It explains perldoc and search.cpan.org, and leaves it to the reader to use those as references.  These are key items often overlooked in books, and rightly deserve a place at the front of the book.

There are several chapters about Perl, the language.  These chapters cover almost all of the language.  They cover it at some depth, pausing to explain how it works and to shine a flashlight into the dark corners and point out all the odd bits you can trip over.  These chapters manage to be easily readable and to avoid most of the technical jargon they don’t need.  When a technical term is needed, it is introduced, explained and then used properly.

The book includes the best description of arity and fixity I’ve ever seen.  I’d gathered the concepts, but didn’t know the names.   I knew the names of the different kinds of operators – infix, prefix, circumfix, and postcircumfix, but have never seen them described so well.  Similarly, this is the clearest and most concise description I’ve ever read of closures, including what they are, why they work, why they’re called “closures” and why they’re interesting.

In addition, the book has the best explanation of why it is important to handle different character sets properly that I have ever seen.  It demonstrates some of the common pitfalls and shows how simple it is to accidentally produce strings which will be unreadable in any format because they’ve got data from two different character sets.  For anyone who isn’t paying attention to Unicode yet, this should be a mandatory read.

There are two chapters on object oriented Perl.  The book starts with Moose and shows its use and how to use it.  Only then does it show the built-in Perl OO constructs.  They’re a lot easier to explain once you’ve seen how objects should work, so you might have a grasp of why you’d be writing a “new” function.  They are well done chapters.

Then come what I considered the important parts!  There are chapters on how to write maintainable code, and what that means.  A chapter discusses some of the common idioms seen on the Internet and on CPAN.  There is a chapter including testing, warnings, and distributions.  There’s a chapter that goes “beyond syntax” to cover why things are done and how to do them well and explains a couple of the common methods used, such as the Schwartzian Transform.  Finally, there is a “things to avoid” chapter and some things chromatic feels are missing from Perl.

I think all of these things are useful and important, and didn’t see anything in the book I strongly disagree with.  I read things I didn’t know, ranging from silly little features (you can us ++ on a string!) to the names of some of the computer science concepts I’d never heard well explained before.  The coverage of the language and how it works is excellent, and reading this will help people go from fumbling with it, to really understanding how it works and why it does the things it does.

My biggest complaint about the book is that I wish there were more of the discussion about writing good Perl.  One of the common complaints about Perl is that it’s ugly, and unmaintainable.  It doesn’t have to be, and there are a lot of techniques to make it better.  I’d have loved to see more discussion of that in this book.  (I realize I have no one to blame but myself, as this book was produced with the collaboration of many and I could have been involved.)

I also just noticed a language feature it missed discussing – formats.  They are another dark corner, but I’m surprised they aren’t there.  Maybe I missed them, but neither a search nor the index shows them.

As you can see, I don’t have much to complain about here, and I’m going to be sending this book around on the internal Perl mailing lists at work.  I feel it’s an excellent place for an intermediate Perl programmer to go to get a really firm grasp on the language and will be an unbeatable way to help many of the self-taught engineers who write Perl to solidify and put names to the concepts they’ve been working with but may not have had such a clear grasp of.

At this point, I’d consider this a more valuable book than “Programming Perl” since it contains so much information about the language that isn’t just in the perldoc.  It’s also less idiosyncratic and contains many fewer in-jokes.  It’s a much more useful and professional book, and I recommend it.

Yeah, you could say that I liked it.

Thank you, chormatic, for the time, work, and effort to produce this!

I work with some excellent engineers, who are thoughtful, intelligent, hard-working folks.  They want to make the best system they can, and they want it to be reliable and dependable.  I have great co-workers.

I keep finding Perl that looks like it was written in 1990.   I find code like this:

sub logger {

    my $msg = shift;

    open(FH, ">>$runpath/log/output.log ")
        || die "Can't write output.log!"

    print FH "$0:  $msg\n";

    close(FH);

}

(Edit: Fixed the mistake that made the sample useless.  Mark Dominus pointed out in the comments that you can’t write to a read-only file handle.  << was wrong.)

The first dozen times I found code like this I thought to myself, “Ugh, old Perl.  Been here for ever.” and cleaned it up.  This is an old codebase – parts of it still have to be compatible with Perl 5.6, for instance – and these constructs weren’t so badly dated when the project began.

I had to stop thinking this while doing a code review of a new change.  Filehandles used with the two-parameter open in brand-new code.

I stopped and asked the engineer why they’d done this.  They looked at me like I was insane.  Of course they’d done it that way – that’s how you open files in Perl.  I had questions: “What about using a lexical instead of the typeglob?”  “What about using the safer, clearer three-parameter form of open?”

I got blank stares.  None of them had ever heard of these changes to open.

I’ve been educating them, which has been interesting.  I’ve also been thinking about how we got here.

There’s two things I see that led to this situation, and both of them are bad for Perl.

First, many of these engineers aren’t aware that Perl is still being developed.  Perl 5.8 was so stable for so long, they’ve quit watching.  They think it’s done, and there’s nothing new under the sun.  They bought “Learning Perl” and “Programming Perl” in 1991 and are happy with both of them.  Neither of those books mentions lexical filehandles  I realized the copy of “Programming Perl” on my own bookshelf didn’t.

Second, it seems like lots of people quit learning about what they’re using.  It’s done, carved in stone, and that’s how they use it.  The idea that the Perl community exists is odd to them, and apparently irrelevent.  The ideas that Perl’s idioms might change or that new libraries, tools, and language constructs come along… these are hard ideas to convey, apparently.  The question I keep getting asked it, “What’s the benefit for making these changes?  What I do works, why should we change?”

Luckily for me, the project leads and our managers do understand why keeping up with the language is important, and I’m not swimming against the current to try and be bringing this new information to the team.  Even so, there’s a couple of big rocks we’re having to go around.

How can the Perl community get past this huge piece of old information about the language?  There are a million web sites with old examples, and thousands of outdated copies of the O’Reilly books on bookshelves.  What can the community do to make it widely known that these are old, and that Perl Is Not Dead and that not only is There More Than One Way To Do It, there’s probably a Better Way now.

I worry that the addition of Perl 6 to the mix will actually make this worse.  Searching for it will be hard, and how will you find examples for one or the other?

I honestly wonder if *both* languages shouldn’t change their names.  Leave Perl 5 in maintenance mode forever and branch it to a new language, even if it’s just Perl 5 with better documentation.  Take that time to reconsider the core modules, clean up some historical messes and release it as something new.  Something that can still use CPAN, can still run all your Perl, but has active development and real, usable tools.  I’d give Perl 6 a new name, too, so you can search for it properly.

Or maybe that’s the worst idea ever.  I don’t know.  I worry that Perl is in a bad spot now, and is trapped in the past.