UTF-8 scripts with BOM not auto-detected #15960
Comments
From @jimav(I can't seem to send purely plain text email, so I'm sending the |
From @jimavThis is a bug report for perl from jim.avera@gmail.com, According to perlunicode(1): That is true for UTF-16 variants, but not UTF-8. #!/usr/bin/perl # Do everything in a temporary directory # Some Perl source code which uses Unicode in identifiers and strings use open ':std', ':encoding(utf8)'; print "ABC" print "The anser is \$\N{U+0444}\N{U+043E}\N{U+043E} (\$\N{U+041E}\N{U+0442}\N{U+0440}\N{U+043E})\\n"; exit \$\N{U+0444}\N{U+043E}\N{U+043E}; # Write out the perl script in various encodings, preceeded by Flags: Site configuration information for perl 5.22.1: Configured by Debian Project at Sun Mar 13 11:54:18 UTC 2016. Summary of my perl5 (revision 5 version 22 subversion 1) configuration: Locally applied patches: @INC for perl 5.22.1: Environment for perl 5.22.1: |
From @maukeAm 23.04.2017 um 03:11 schrieb (via RT):
Duplicate of https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121292 ? -- From perl5-porters-return-244160-rt-listener=rtperl.dev@perl.org Sun Apr 23 02:27:20 2017 On 23 April 2017 at 11:13, Lukas Mai <plokinom@gmail.com> wrote:
If it is I will just say that i think this issue could be reopened. I I think we should have respected the docs and added support for Maybe we should re-enable this on Windows, or make it be a build option. Yves -- From perl5-porters-return-244161-rt-listener=rtperl.dev@perl.org Sun Apr 23 03:14:59 2017 Am 23.04.2017 um 11:27 schrieb demerphq:
The problem I'm worried about is that we already see problems from users $ ./my_script.pl when my_script.pl clearly exists. This failure mode is caused by the #!/usr/bin/perl\r Similarly, an invisible BOM at the beginning would completely break the PS: I like "Perl5 Porteros" :-) -- From perl5-porters-return-244162-rt-listener=rtperl.dev@perl.org Sun Apr 23 04:11:23 2017 On 23 April 2017 at 12:14, Lukas Mai <plokinom@gmail.com> wrote:
Interesting. My response to that is "so lets make that work as well, My point here is that it seems to me that most of these failure modes
I think that was the name someone had given it who I replied to first Yves -- From perl5-porters-return-244163-rt-listener=rtperl.dev@perl.org Sun Apr 23 05:01:22 2017 Am 23.04.2017 um 13:10 schrieb demerphq:
If you want to make that work, you have to go out and patch all unixish (I suppose you could fix that by doing `ln -s perl $'/usr/bin/perl\r'` But even that won't help you with a BOM: Either it will fail outright -- From perl5-porters-return-244165-rt-listener=rtperl.dev@perl.org Sun Apr 23 12:33:30 2017 Bisecting shows that the warning started appearing for that test script Attempting to minimise the test script, it turns out that the "use $ perl ../rt131190 Looks like the problem is that the check for wide characters should be -zefram |
|
The RT System itself - Status changed from 'new' to 'open' |
From @demerphqOn 23 April 2017 at 11:13, Lukas Mai <plokinom@gmail.com> wrote:
If it is I will just say that i think this issue could be reopened. I I think we should have respected the docs and added support for Maybe we should re-enable this on Windows, or make it be a build option. Yves -- |
From @maukeAm 23.04.2017 um 11:27 schrieb demerphq:
The problem I'm worried about is that we already see problems from users $ ./my_script.pl when my_script.pl clearly exists. This failure mode is caused by the #!/usr/bin/perl\r Similarly, an invisible BOM at the beginning would completely break the PS: I like "Perl5 Porteros" :-) -- |
From @demerphqOn 23 April 2017 at 12:14, Lukas Mai <plokinom@gmail.com> wrote:
Interesting. My response to that is "so lets make that work as well, My point here is that it seems to me that most of these failure modes
I think that was the name someone had given it who I replied to first Yves -- |
From @maukeAm 23.04.2017 um 13:10 schrieb demerphq:
If you want to make that work, you have to go out and patch all unixish (I suppose you could fix that by doing `ln -s perl $'/usr/bin/perl\r'` But even that won't help you with a BOM: Either it will fail outright -- |
From @jimavOn Sun, 23 Apr 2017 14:32:33 -0700, plokinom@gmail.com wrote:
IMO, #! support is semi-off-topic. The problem at hand is that you can't say I just dont' see how any harm could come to *nix users if Perl recognizes the BOM *and* acts accordingly Deliberately making life harder for users, even (gasp) users on Windows, should be done only with very compelling reasons! I don't think a file starting with a BOM could legitimately contain non-Unicode characters. If there is a BOM, the file was created by Unicode-aware software (e.g. Notepad), and absent a bug or major user shenanigans, the file is certain to contain Unicode characters encoded as the BOM indicates. BTW, a BOM is not invisible if you look at the file with vim -b. |
Migrated from rt.perl.org#131195 (status was 'open')
Searchable as RT131195$
The text was updated successfully, but these errors were encountered: