New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
open sometimes ignores perlio layers when duping #7854
Comments
From ambrus@math.bme.huCreated by ambrus@math.bme.huIn some cases, the 3 argument open statement of perl ignores perlio For example, this command: 'open opens a duplicate filehandle for STDIN successfully, but does not apply the open successfully apply the encoding layer to the dupe handle, while the original The io layer part of the string is sometimes ignored, sometimes it is open open a dupe filehandle but not apply the layer. If you mis-spell the open fails with EINVAL and warns 'Cannot find encoding "iso-8895-2"' (which is, open opens the dupe ignoring the layer part completely. I've written a test script to test some of these bugs. This one does not 28-30, 33-35, 38-40, 43-45, 48-50, 88-90, 93-95, 98-100, 103-105, 108-110 I also get a few wide character warnings from the test, which are also Even though this perlbug is that of perl 5.8.5, I've also got the same I tried to trace the error to its origins. I belive the error is in the ambrus ----------------------------------------------------------------- use warnings; use Test::More tests => 120; use IO::Handle; sub any { for my $dup_descriptor (0, 1) { __END__ ----------------------------------------------------------------- Perl Info
|
From @demerphqOn 28 Mar 2005 14:46:54 -0000, via RT Zsban Ambrus
FWIW: I checked this on blead and i got the same results as Ambrus. cheers, -- |
The RT System itself - Status changed from 'new' to 'open' |
I believe this bug still exists on 5.30.2. Test script below. What seems to be happening is the PerlIO layers are copied from the handle being duped to the new handle, and any layer specification in the 3 arg open is completely ignored. I get the same results whether the $target handle is STDOUT or a handle I've opened myself.
Output:
|
And also the output is identical whether using a |
…icate utf8 encoding for regular output. The combined call to open() that was supposed to duplicate the STDOUT file descriptor and select a raw encoding at the same time did not work. It is a bug in Perl: Perl/perl5#7854 But a separate call to binmode worked, as documented here: https://stackoverflow.com/a/27802183 The fault was not apparent when Lintian ran in a terminal. It only became a problem when piping JSON output to a file in the archive tag sieve. Maybe gnome-terminal reversed the duplicate encoding magically. Removes a duplicate encoding layer on STDOUT, which was apparently not a problem here. PerlIO::get_layers reported for $RAW: unix perlio encoding(utf-8-strict) utf8 encoding(utf-8-strict) utf8 After this commit it gave the expected values: unix perlio
FWIW — I just ran into this under 5.36, even when I don't specify any encoding layers in the 3-arg open. (I also find it interesting that I get different behavior when STDOUT is a pipe versus a TTY, etc.)
|
Migrated from rt.perl.org#34595 (status was 'open')
Searchable as RT34595$
The text was updated successfully, but these errors were encountered: