On Sat, Jul 31, 2021 at 4:29 AM 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 is the "default" in the sense of "what you get in the absence of explicit declarations like use utf8 and no utf8". (Is there a better word?) EirikThread Previous | Thread Next