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 LocaleIn 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)
In reply to Re: approaches to debugging a platform-dependant bug
by graff
in thread approaches to debugging a platform-dependant bug
by bcrowell2
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |