rlucas.net: The Next Generation Rotating Header Image


[FIX] Adobe Reader v.5 fails to open PDF with "There was an error opening this document. A temporary file could not be opened."

If you see “There was an error opening this document.  A temporary file could not be opened.” when trying to open a PDF file, you may need to clean out C:Documents and SettingsUSERNAMELocal SettingsTempAcr*.tmp

Cheers to “gprellwitz” who suggests this here:


Jeers to the MSFT developer who decided that “Documents and Settings” with spaces and mixed caps was a better home directory prefix than “home”

BUG/FIX: Empty "script" tags may cause IE to display nothing

I use Microsoft Internet Explorer version 6 (IE6) on Windows 2000 when
I have to (much better to use Mozilla or Opera in my opinion; even some
of the Microsoft guys are now eschewing IE for security reasons). 
I tested a document that passed some pretty strict validation and was
showing up fine in Mozilla, under IE6.  The title appeared, but
the body was blank.  What?!

It turns out that the problem was independent of quirks mode on/off
(google for quirks mode if you don't know).  It was dependent upon
two “<script language='javascript' src='blah' />” tags in the
<head> section.  By changing the <script /> to
<script></script> (explicit closing tags), the body
reappeared OK.

[FIX] DBD::mysql installation on Red Hat 9 fails with "Unsuccessful Stat" messages.

If you go to install the Perl module DBD::Mysql on Red Hat 9 with MySQL 3.23 (and probably other versions as well), two gotchas might appear.  First, if the MySQL bin directory is not in your path, then you won't be able to have it pull the options automatically.  Make sure that when the Makefile.PL runs (either because you're running it or CPAN is) it can find and run mysql_config.


The second gotcha is that Red Hat shipped 9 with default LANG=en_US.UTF-8 in the shell environment.  This will cause your makefile to have some oddly malformed lines around line 89, and will cause a blizzard of these complaints:

Unsuccessful stat on filename containing newline at /usr/lib/perl5/5.8.0/ExtUtils/Liblist/Kid.pm line 97.


The solution, according to the kind David Ross at Linuxquestions.org, is to

export LANG=C

before running Makefile.PL. Many thanks.





[BUG] ActiveRecord woes with SQL Server odd names (spaces and brackets), ntext data types

ActiveRecord (latest versions of ODBC, DBI, and AR as of today
2005-12-01) seems to be having trouble with at least two things that
SQL Server 7 does:

1. The SQL Server adaptor (sqlserver_adaptor.rb) get_table_name sub
expects a name to have no whitespace in it.  The conditional and
regex need to be changed to look for bracketed names like [Poorly
Designed Table].  Then, the columns sub needs to know to take the
brackets off the ends of the names when it looks up the table by its
textual value.  To complicate this, according to
http://msdn2.microsoft.com/en-us/library/ms176027.aspx you can have
either double-quotes or square brackets as your delimiters in SQL
Server names, and you can even escape brackets by doubling.  I
have written hackish code that solves for simple [Dumb Name] tables but
not the whole enchilada, so I'm not posting it here yet.

2. The data type “ntext” seems to create memory allocation problems; I get an error of:

/usr/lib/ruby/site_ruby/1.8/DBD/ODBC/ODBC.rb:220:in `fetch': failed to allocate memory (NoMemoryError)

Running this on CYGWIN_NT-5.1 RANDALL-VAIO 1.5.19s(0.141/4/2) 20051102 13:29:13 i686 unknown unknown Cygwin on Win XP Pro.

[HINT] Preprocessing mongo XML files for use with XML::Simple

If you are a reasonable Perlista, the first thing you will do when you
have to do some modest but non-trivial munging of data locked up in XML
is to use XML::Simple.  The API is nearly perfect (absent the lack
of some defaults that could be more helpfully set for strictness) for
purposes of comprehensibility and transparency.

However, if you prototype on a small document, and then try to use your
code on a much bigger XML document, you will find the drawback:
tree-building is costly, and you may spend the vast majority of your
program's time parsing in the document.  One handy solution is to
preprocess your XML — just run XML::Simple's XMLin sub, and use
Data::Dumper to spit out the structure that results to a file. 
When you want to use it, you can simply “eval” it, for it defines a
native Perl structure, and you can use the remainder of your code
unchanged.  This resulted for me in a 2x – 10x speedup for certain
documents and certain sizes.

However — now imagine that you have some real torture-test data — 10
MB, heavily nested monstrosities of XML.  The Dumper output of the
parsed tree is now working on 100 MB!  Slurping this in and
evaling it is now the real problem.

Here's an idea: rather than slurping and evaling, try inlining it at
the compilation stage.  That's right — make use of Perl's much
more efficient way of slurping and evaling a filehandle with a pipe:

cat preprocessed_xml.dd myscript.pl | perl

It's somewhat unorthodox, but entirely functional.  Combined with
judicious use of gzip, this could be a very efficient way to get
little-changing XML documents into perl quickly — often very important
when doing dev work for which numerous iterations are required and for
which a minutes-long parse stage would adversely affect progress.

Update: It occurred to me that
using Storable or a Cache::* module might be faster yet.  At this
point, my work proceeds with tolerable speed using Data::Dumper, plus I
like using Dumper so that I can edit the output structures by hand if
need be.  But perhaps you should try those modules if you need
even better performance, or cringe at the hackishness of catenating
files piped to perl.

"Can't coerce GLOB to string in entersub" means "File not found"

For users of the Perl modules XML::LibXML and XML::LibXSLT, you will save yourself much puzzlement if you understand that “Can't coerce GLOB to string in entersub” really means “file not found.”

NOTE that the file which is not found might be your XML, your XSLT, or the schema / DTD for these things! Maybe some -e tests are in order (but don't forget that filenames hidden in your XML pointing to bad DTD paths, for example, will throw the same cryptic error).

See also http://maclux-rz.uibk.ac.at/~maillists/axkit-users/msg05794.shtml

WORKAROUND: Excel for Mac toolbars "trapped" off the screen

If you hook up an external monitor to your Mac OS X machine and run Excel 2004 for Mac on it, you might move your toolbars completely or partially over to the second desktop area. If you then remove the external monitor, it is possible for the toolbars to get “stuck” such that only a corner (like the resizing corner) is visible. You can resize them, but not move them back onto your main screen.

You can try to use “Reset” in the View:Toolbars:Customize Toolbars/Menus, but that doesn't work. There's some other reset-to-defaults choice somewhere that I tried (and can't find now) that didn't work either. Quitting and restarting does nothing.

Try going into your home directory (/Users/username) and nuking this file:

/Users/username/Library/Preferences/Microsoft/Excel Toolbars (11)

Upon restarting Excel, they were back to normal location. Problem solved (except for the braindead engineering).

[BUG] Lotus Notes sending malformed base64 encoded attachments

It appears that Lotus Notes occasionally sends malformed base64
encoded attachments.  I received a message from a Notes user that
was a forwarded message; the old message got hamburgered.

Others?  Appears so.


We especially suffer this with our RT installation.  No particular word on a fix at present.

Downgrading to Apache 1.3 from Apache 2 under Red Hat 9

Apache 2.0 can be a real cast-iron bitch.  It's got this cool
support for threading that you think will make your life easier but it
turns out to have all sorts of little API differences that break your
legacy apps, in really horrifyingly difficult to discern ways. 
This might be the apps' fault or Apache's fault, but either way it
makes your life hard if you are used to things working smoothly under
Apache 1.3x and then get jolted into the cruel world of 2.x.


Red Hat has put out Apache 2.0 since at least Red Hat 8.0.  Red
Hat 9 comes with Apache 2 as well.  However, Red Hat knows about
the problems as well as anybody: the non-gratis Red Hat Enterprise
Linux distros come with Apache 1.3x!  [UPDATE: Enterprise
Linux 2.x came with 1.3.x; Red Hat has made
the questionable choice of putting Apache 2 in Enterprise Linux
3.0 and removing things like the venerable Pine…] 
It's clear that if you actually want stability, you should use 1.3
until the rest of the world catches up with Apache 2.0.

(Other people know this too: see http://linux.derkeiler.com/Mailing-Lists/RedHat/2003-07/0726.html and http://lists.freshrpms.net/pipermail/rpm-list/2003-May/004682.html )

If you want to downgrade your Red Hat 9 Apache version, you can
either try to compile, which is fairly straightforward once you find
the fixes I mention below, but if you want mod_perl and mod_ssl, and if
you are not very smart, like me, you really are better off using the
rpm packaged versions.


Unfortunately, the openssl 9.7 that comes with Red Hat 9 will
prevent you from installing mod_ssl 2.8 to go with Apache 1.3. 
So, here's how to install Apache 1.3 with mod_perl and mod_ssl:


1. Erase the apache 2.0 rpm from the system.  Nuke the dependent packages as well (mod perl, mod ssl, php, etc).

2. Get:





 Warning: these packages are
end-of-lifed and may present security hazards (read: your box could be
owned if you do this!).  I am no longer running a box with these
packages and I suggest you do not either!  I currently recommend
apachetoolbox (apachetoolbox.com) for a quick and relatively painless
recompile, rather than relying upon these old dusty rpms.

3. Install apache and mod_perl.  Ensure that it works fine (sanity check).

4. Back up /usr/share/ssl/* to e.g. /usr/share/ssl9.7a/

5. Back up /usr/bin/openssl to e.g. /usr/bin/openssl9.7a

6. Install openssl with a suitable command line:

rpm -ivh openssl-0.9.6b-32.7.i386.rpm –excludedocs –oldpackage –force

7. Now back up /usr/share/ssl/* to /usr/share/ssl9.6b/ and restore ssl9.7a/

8. Back up /usr/bin/openssl to openssl9.6b and restore openssl9.7a

9. You should now have both openssl 9.6b and 9.7a installed on your system.  You can verify this with rpm -q openssl

10. Now install the mod_ssl RPM.


Make sure you've used lokkit (or manually arranged) to open up both
port 80 and 443 or else you'll drive yourself crazy for 20 minutes,
like I did, wondering why http is running but not answering.

[BUG/WORKAROUND] Microsoft Outlook 2003 / XP can't import vCard notes field; Entourage on Mac can

I am trying to sync my contact information between apps and machines. Here are my absolute, non-negotiable requirements:

with” means I can round-trip in the given format — not necessarily
that it is native, and it's OK if I have to use a tool or a script
intermediary since I'll be scripting this stuff anyhow.)

1. Works with Outlook.

2. Works with Address Book on Mac.

3. Works with abook from the command line.

4. Is editable text in case I need to switch platforms, or do revision control, or any of a host of things.

was good with some kind of cobbled-together vCard solution, until I
discovered that MS Outlook 2003 on Windows XP could export note:
fields in .vcf files (oh, and insult to injury — there is no “Export”
option to vCard, you have to do some right-clicky nonsense or else
highlight all your contacts and “Forward as vCard”) but would not
import those same notes!

Outlook does not round trip a fully-spec'ed RFC standard?!?! What the hell?

(?) my workaround is to use MS Entourage for the Mac, which will
round-trip appropriately and sync itself with the Exchange server at my
work.  For those who cannot, perhaps there is a VBA
solution.  If you have one, please comment; I will update if I
discover how to get Outlook 2003 to accept the notes fields.