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
IO layer for STDERR not set #15392
Comments
From @chorobaCreated by @chorobaWhen reopening STDERR, its encoding layer doesn't change. #!/usr/bin/perl open STDERR, '>:utf8' , 'perl.log' or die $!; Output (contents of the perl.log file): (???) Expected output (works OK if I use LOG instead of STDERR, or my $LOG, (éèçà) Origin: http://www.perlmonks.org/?node_id=1165214 Ch. Perl Info
|
From zefram@fysh.orgE. Choroba wrote:
This actually happens when, and only when, reopening a file handle that /* Eeek - FIXME !!! The issue is that the new handle configuration is initially opened on a -zefram |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgThe problem of this ticket interacts nastily with threads. Without threads, the same-fd-on-reopen semantic makes sense. Each file Threads complicate things because each file handle is duplicated into each The desire to reuse a low fd number when reopening a handle conflicts A similar issue arises with the ">&=" open mode. This sets up sharing The treatment of reopening with a shared fd is really a distinct bug from A relatively simple possible answer is that a fd can only be reused if -zefram |
Migrated from rt.perl.org#128365 (status was 'open')
Searchable as RT128365$
The text was updated successfully, but these errors were encountered: