Programming Bits & Pieces

Every so often (well, quite frequently if I'm being honest), I run into a problem when I'm developing a system. Usually the answer can be found by asking a colleague, re-reading the manual or by searching the web or Usenet -- a technique summed up by the abbreviations RTFM & STFW. Sometimes this technique lets me down, however, so I'm going to try to build up a (hopefully small) list of problems I've solved which I couldn't readily find a solution to elsewhere. If it helps someone else out, so much the better.

Embedded Perl

I've been using this quite a bit recently and have to say I really like it for creating small-to-medium sized sites. It's an awful lot better than vanilla CGI -- being something of a cross between PHP and Perl and seems to run at a decent speed, too. For more information the official website is here.

Recently I had some weird errors though. A simple Perl use statement was causing Embedded Perl to spit out syntax errors, for example:

[- use Somewhere::MyPackage -]

which would produce such utter nonsense on output as:

ERR: 24: Line 37: Error in Perl code: syntax error at MyPackage.pm line 1, near "package Somewhere::MyPackage"
BEGIN failed--compilation aborted (in cleanup) syntax error at MyPackage.pm line 1, near "package Somewhere::MyPackage"
BEGIN failed--compilation aborted at /usr/local/apache/htdocs/base.epl line 38.

Now if you know even a tiny bit of Perl this output is ridiculous. It's claiming that the use command is invalid Perl. Rubbish!

After much heartache and tearing-out of hair I eventually stumbled upon the solution. Although generally Embedded Perl doesn't require single-line statements to be terminated with a semi-colon, in the case of the use statement it is necessary. All I had to do was change my line of code to:

[- use Somewhere::MyPackage; -]

and everything was fine again. Wierd. And extremely difficult (not to mention annoying) to track down. It is actually mentioned in passing in the Embedded Perl documentation but it's not exactly emphasised and I'm sure I'm not the only person to overlook it.

CDRW and UDF

Now here's a thing that I didn't know (although I dare say everyone else was fully aware of this and I'm the last person in the world to find out). CDRW (rewritable CDs) can be formatted in a number of ways but one of the more common is the rather optimistically-named Universal Disk Format (UDF).

What this means in practice is that if a CDRW disk is inserted into the CD-ROM drive of a computer which has never had any CD-writing software installed it's quite possible the operating system won't recognise the disk format. Which of course means all the data which has been lovingly and carefully copied onto the CDRW is completely inaccessible! In terms of Microsoft Windows this applies to all versions prior to Windows 2000, as I recently found out when I tried to read a CDRW disk in a machine running NT4 SP6.

A quick Google search revealed the problem: as stated above I needed drivers to teach my machine how to read UDF format. Obtaining the drivers was another matter, which is ultimately why I've put this information together here. Most of the links and articles I read pointed me to Adaptec, who have free UDF driver support for Windows available as a download, to support their CD-burning packages.

The problem here is that Adaptec have now sold off their CD-burning software to Roxio, and Roxio's support and downloads page is difficult to navigate to say the least. Eventually I did find the relevant drivers though. It's a half-megabyte self-installing file, which (at the time of writing at least) is available as a link from the very bottom of this page. With luck, this information will be of use to someone else, too!

Debian: Unable to log in, either remotely or via tty console

This was a weird one which hit me recently. I was attempting to ssh into my main Debian box at home but couldn't get past sending my passphrase -- the ssh connection would just hang at that point and eventually time out.

Obviously I was more than a little concerned, and as soon as I got home from work I went over to the console to try to connect. No luck connecting as my usual user, so I attempted to log in as root. Nope, every time I got as far as entering my password, and there the login process would hang. Now I was getting seriously worried -- perhaps my box had been compromised?

I was ready to use the time-honoured CTRL-ALT-DELETE to reboot the system (yep, that can be made to work even on GNU/Linux systems), but just before I did that I thought I'd check the system logs. The default Debian /etc/syslog.conf file contains a line which will log all system log output to /dev/tty8 -- the screen which is accessed by pressing the F8 on the keyboard. Seeing as this particular machine's main function is to be an internet gateway/router I usually leave it displaying this console. Flicking over to tty8 I noticed that the most recent entry was dated 11:53 -- yet the time now was 18:03. Aha, a clue! I quickly hit the Scroll Lock key and pages and pages of log data scrolled past me.

Having seen this I then went back to a normal console with a login prompt, and tried again. Success! I could now log in again, and all was OK with my machine. Wondering if anyone else had come across this, I did a web search and came across this and this (both entries in the Debian bug archive indicating that this was a known, if slightly obscure, error.