Cookbook Advice

gnat on 2003-04-08T01:00:56

I'd forgotten just how much good advice there is in the Cookbook. I'm pounding on ch07 now, and this involves looking closely at every word (because filehandles have changed more than, say, the CGI module). I just noticed and remembered the advice about choosing file permissions with sysopen (it's on page 228 for those of you following along at home).

Basically, use 0666 for regular files and 0777 for directories. This because the user can always remove permissions they don't want by setting their umask, but there's no way to be more permissive than the program's hard-coded value. So give the user choice, but don't take it away.

This was Tom's advice--I wasn't particularly umask-clueful when we were writing the book. He really pushed me to learn exactly what it was and how it worked. Ah, good days.

This, thankfully, is one thing that won't have to be updated for these heady 5.6 and 5.8 days!

We've had a long to-and-fro about the virtues of retaining bareword FILEHANDLE syntax versus going with the new $fh filehandle-as-variable syntax made possible by:

open $fh, ...
I'm the progressive force, as I was on the old Cookbook, always arguing for the new stuff. He's the traditionalist, able to muster a million arguments why the new stuff is crap :-) He won on this not because $fh is necessarily worse than FH, but because we've used $THING in snippets to indicate a variable or value that you'd need to initialize before you can use the snippet. It makes sense to retain that uppercase convention, and it seems silly to add a $ to filehandles in hundreds of snippets without any compelling reason.

I have to say, though, that I'm in love with

open $fh, ...
I love being able to lexically scope my filehandles. (ha, get it? "my" filehandles? Oh I kill me). And the new three-argument form of open kicks ass. You can read/write to strings with the builtin open now, for pete's sake!

open $fh, "<", \$string
Now that's making easy things easy.

--Nat


my filehandles

pudge on 2003-04-08T02:35:28

I love doing:
open my $fh, $file;
Something about that inlined my makes me feel funny!

I always advise people to use lexical filehandles

Damian on 2003-04-08T06:58:31

Mainly because I've seen far too many people land in debugging hell simply because they forgot to localize a filehandle and were too lazy to name it anything but FILE. Like everybody else does.

Globals bite (in both senses ;-).

bah

jhi on 2003-04-08T16:12:47

Tom may talk all he wants :-) but I prefer 0644 for files and 0755 for directories. Maybe I just do not trust users.

Me too!

jjohn on 2003-04-09T03:30:39

I'm forcing myself to use lexical handles these days because FILEHANDLES are fraught with peril, as Damian points out. However, I recently found a place where vanilla socket FILEHANDLEs seem to work better with select(2) than IO::Socket does. This fills me with angst and consternation, because I don't understand why select(2) appears to not see a perfectly readable socket. I'm still uncovering the details (hint: it involves _need_more() in HTTP::Daemon) and will certainly blog the results when I'm ready. Most people I know phear select(2) and that's a Bad Thing (tm).

More advice about Perl systems programming is always desirable (I'm writing several perl daemons these days).

Also, I'm with the CPAN King: 644 those files! If I'm charitable: 664 (I guess I can trust lusers in my group). ;-)

Remember, ssh doesn't like identity files group and other readable bits set. That's paranoid! My attitude is merely cranky in comparison.

Recipe 15.17 comment

runrig on 2003-04-17T22:50:54

I wasn't using Tk (I was actually trying out Wx), but that "Removing the DOS Shell Window.." thing didn't work, at least not with my Win95 and ActiveState perl 5.6.1 setup (the original console window was left open until the spawned process was finished). After some googling, I found this, which did work:
BEGIN {
  if ($^O eq 'MSWin32') {
      require Win32::Console;
      Win32::Console::Free();
  }
}
Doing it this way also made it unnecessary to start another process. (Is it too late to get this in the book? :-)