Front page | perl.perl5.porters |
Postings from July 2021
> On Jul 30, 2021, at 22:29, Dan Book <grinnz@gmail.com> wrote: > > >> On Fri, Jul 30, 2021 at 10:15 PM Eirik Berg Hanssen <Eirik-Berg.Hanssen@allverden.no> wrote: > >>> On Fri, Jul 30, 2021 at 8:28 PM Leon Timmermans <fawaka@gmail.com> wrote: >> >>>> On Fri, Jul 30, 2021 at 7:56 PM Felipe Gasper <felipe@felipegasper.com> wrote: >>>> >>>> It’ll downgrade it, but it won’t encode it, so you’ll get mojibake: >>>> >>>> > perl -Mutf8 -e'print "é"' >>>> � >>> >>> It will print mojibake as well if the script is latin-1 encoded. It's mojibake because the terminal is utf-8, but the IO handle is latin1. >> >> In this case there is no "script" other than the command line, in the terminal. Round-tripping characters from the terminal to the terminal, broken. Sounds painful. >> >> I'd expect the encoding to be the same for the code as for the standard handles, unless either is otherwise specified. It would surprise me if a simple perl -E broke that. >> >> I'm leaning towards thinking that, while there's no problem with lexical, explicit declarations of source encodings, the default source encoding is more of a global thing, and to avoid nasty surprises, ought to correspond to the default encoding of the standard handles. > > This isn't the "default", it's the entire function of "use utf8" and only applies to that lexical scope. It’s not “default”, but feature bundles are a sort of “quasi-default”, as in, “modern Perl starts with a feature bundle.” They usually just enable useful stuff, breaking “outlier”-type things (like custom functions named say()). If “modern Perl” heightens the requirement to juggle text vs. byte strings, providing no lifeline to help distinguish one from the other, that seems to me to make the language harder to use, not easier. -FThread Previous | Thread Next