Markus Wichitill wrote:The reason for the failure is pretty clear, the BOM ends up somewhere in the middle of the string that is eval'ed to generate the package. On Linux, I was able to fix that by removing the BOM in RegistryCooker::read_script():
It's certainly a bad idea to add any s/// in the code, since it's slowing things down. And it certainly shouldn't be a penalty for most other users who don't have this problem. So this can be done in a subclass of RegistryCooker.
Fine by me, I've told my editor to not save UTF-8 BOMs anyway, since the shell (kernel?) and mod_cgi on Unix can't deal with them, they break the shebang line.
$ ./test.pl ./test.pl: line 1: #!/usr/bin/perl: No such file or directory
But first I would like to know why the script doesn't fail when run outside mod_perl. We do nothing special here, other than read+eval, compared to require. So it looks like a bug in perl.
No, Perl can deal with a BOM at the start of a file. But convert_script_to_compiled_handler() puts the BOM in the middle of the string that is eval'ed. A bunch of raw bytes has no place in the middle of a script.
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
