First step of all steps would be to get an accurate error description. Maybe you have it already, but I think it would help if you shared that error description with us.

From what I've seen, there are some problems with the locale set on Red Hat systems - I think that Red Hat exports LANG=en_US.utf8 or something like that which has given people grief. Maybe deleting that entry from the environment or setting it to "C" or something like that helps.

As a general idea, I'd go for one of the many virtualization packages and run Red Hat in a virtual machine - almost every modern operating system offers virtual machines to contain other operating systems.

You're of course completely correct about getting the exact error message, and I'm an idiot for not having that handy. I've e-mailed one of the red hat users to ask him for the specific error message.

Your idea about $LANG is interesting. What I'm doing is this:

if (exists $ENV{LANG}) {
  $ENV{LANG} =~ m/^(..)/;
  $preferences{'language'} = lc($1);
}
[download]

So if red hat sets it to "en_US.utf8", it seems that the language would still be correctly recognized as "en". However, I think it's very likely that something along the lines of what you're saying must be the problem. Just on general principles, I should probably also do more error checking and sanity checking on the language code I'm extracting from $LANG.

I'm sorry, but these days, RH-9 and perl 5.8.0 are not that current, and on top of that, this particular combination has some known problems that stem from the fact that perl's treatment of file i/o was dependent on the user's locale environment. From the "Perl 5.8.1 Official Announcement":

UTF-8 On Filehandles No Longer Activated By Locale

In Perl 5.8.0 all filehandles, including the standard filehandles, were implicitly set to be in Unicode UTF-8 if the locale settings indicated the use of UTF-8. This feature caused too many problems, so the feature was turned off and redesigned...

The problems involved getting a lot of mayhem from existing apps, which folks were expecting should have ported seemlessly from 5.6 or earlier, and had nothing to do with unicode data. They broke because instead of reading data "as-is", the user's default locale setting (which on RH9 involved utf8) was treating any sort of non-ascii data as something unexpected, usually producing "malformed utf8" errors.

I think the best fix might be to put "use bytes" at the top of the script (assuming this is appropriate) -- though I'm not sure if this is always adequate. Another idea would be to check the perl version and OS, and if it's 5.8.0 on RH9, apply binmode ":raw" on file handles, to disable the treatment of file i/o as utf8 (assuming this is appropriate).

You'll still need someone with that combo to serve as a beta tester. Someone might be willing to give you a user account on such a box, and if so, you can debug on your own. But short of that, package up a minimal app and test data that would demonstrate the problem you need to fix, and ask a beta tester with the target setup to run it and send you back the output. Iterate till you get it solved. (Bummer)

Thanks for the very informative post! I've verified now that it runs fine when I boot from a Fedora Core 3 bootable CD, which supports your hypothesis about that specific version of red hat and perl.

If you want to go for the Live CD approach, you might find a RedHat like live CD on http://distrowatch.com.

Thanks for the pointer to distrowatch! I downloaded a bootable CD called Adios, which runs Fedora Core 3, and verified that the program runs fine on it. So it looks like this problem only exists on specific older versions of Red Hat.

This is where virtualization really shines. Get a copy of the free VMWare player, XEN or another favorite virtual machine tool, install RedHat and test! Linux Journal just did an issue with articles on virtualization. I know developers who have four simultaneous virtual machines up and running constantly to test apps on different platforms. Way cool and easy to implement.

--traveler

Hmm...I checked out vmware and xen, and decided to give xen a shot, since it's open source, and vmware isn't (?). I got xen runnning from the demo cd, but unfortunately Red Hat isn't one of the options that comes on the demo cd. Then I started working on getting a full install of xen working, but after putting a few hours into it, it looks like that's just beyond my expertise. Cool idea, but in my case, with my skills, it just doesn't seem to be practical.

The info on redhat and Xen is here.

Also check out Qemu. It is a true processor emulator (but does have an accelerator to use the actual CPU):http://fabrice.bellard.free.fr/qemu/