It seems we can't write a training course without picking up more things in Perl to improve. When pjf started writing our OO course he decided that NEXT didn't go far enough to solve certain inheritance problems. I think NEXT::UNSEEN (now NEXT::DISTINCT) was already there but NEXT::ACTUAL was proposed from writing our course.
Of course it couldn't be left there and eventually EVERY was born, but that didn't have a lot to do with us.
Now we're writing a security course and pjf's decided that Perl really should have a way of manipulating saved user/group ids. I agree entirely. How else can you permanently drop privileges? So Proc::UID was born and is now under development. Furthermore Proc::UID will never cache its values, did you know that $<, $>, $( and $) do?
Yesterday we reviewed my section on Safe.pm. I'm not a Safe guru, but it appears that very few people are. Finding material to use so that I could learn about Safe was challenging. But I managed to get what I thought was enough of an idea. We've decided that my section on Safe now raises more questions than it can answer.
We want people to use good programming practices. That means that it would be good if their compartmentalised code could be compiled with strict and warnings enabled - ideally. But that means giving the compartments the ability to require things, which is no good...
Furthermore, compilation errors inside compartments are hard to find. The eval error gives you a line number but if you've got more than one compartment you may have to guess which one to start looking at.
Safe's rdo uses Perl's do. Unfortunately this means that you can use return a list of things when you use reval but only a single thing (including a reference) when you use rdo. Of course, this isn't documented anywhere I looked, so that was a bit surprising.
This means that we spent the better part of an hour talking about how Safe could be elegantly improved to work around these problems. Maybe Perl has a concept of original line numbers (like C does) which it can share will eval (and hence be used by Safe's reval)... we will have to look. How can we share our scripts strict with the compartment... do we need to rewrite either do or rdo?
We want to promote using Safe for writing easily auditable code (the code in this compartment doesn't touch the filesystem and can't do much so it's less interesting than this other compartment which does). But it's clunky and painful at the moment. So it's on the stack of things to improve. Step 1 is to find out if there's a mailing list for it. ;)
The stack also includes providing Perl with a mechanism to use secure memory and a number of other fun problems. We're keeping busy.
Look at the last section on "Plain Old Comments (Not!)". That method can be used to set Perl's notion of the line, file, and package to whatever you want. Set them to something descriptive and useful.
I've used the same technique with eval for years after merlyn pointed it out to me on Perlmonks.
