This is wrong, it has nothing to do with the UTF8 flag, see demo program below. The reason why open A in your example creates a file with a name that is broken for display purposes only¹ is because you (implicitly) used an encoding (namely, Latin1) that does not agree with the encoding of the filesystem² (namely, UTF-8).
If a programmer does the straight-forward thing that comes to mind, namely just using a string, not even bothering to encode to octets, then there is no problem. Both strings and UTF-8 encoded octet sequences work. I personally haven't even run into the problem during the last ten years because it requires special action to set oneself up for failure in order to trigger.
To come back to the topic expressed in the root post, I think nothing needs to be done for Posix. This is a Windows only bugfix.
¹ The big difference to the Windows shitshow where system calls do not work and return error messages, on Posix they do work even if you somehow fuck up the encoding. The file will exist, will be enumerable, will create a filehandle you can operate on, merely the name will display wrong.
² De jure the encoding of a Posix filesystem is unknown and unknowable, but de facto it is UTF-8. I remember dwheeler is doing work to get UTF-8 as default into the next version of the standard, but I can't find the relevant document on the Web.
use 5.026;
use utf8;
use Devel::Peek qw(Dump);
my $string = 'string-año';
# FLAGS = (POK,IsCOW,pPOK,UTF8)
# PV = 0x12f4760 "string-a\303\261o"\0 [UTF8 "string-a\x{f1}o"]
my $octets_latin1 = "octets-latin1-a\x{f1}o";
# FLAGS = (POK,IsCOW,pPOK)
# PV = 0x12f4420 "octets-latin1-a\361o"\0
my $octets_utf8 = "octets-utf8-a\x{c3}\x{b1}o";
# FLAGS = (POK,IsCOW,pPOK)
# PV = 0x12ebb00 "octets-utf8-a\303\261o"\0
my $fh; # ↓ displays in shell as: ↓
open $fh, '>', $string; # string-año
open $fh, '>', $octets_latin1; # 'octets-latin1-a'$'\361''o'
open $fh, '>', $octets_utf8; # octets-utf8-año
| [reply] |
My point is that two variables that eq sees as containing the same value, create two different files just because of its internal representation.
The representation used by perl internally, should not affect external interactions.
Update: BTW, note that in my sample repl above I have used utf8::upgrade which just changes the representation. Quoting utf8:
Converts in-place the internal representation of the string from an octet sequence in the native encoding (Latin-1 or EBCDIC) to UTF-8.The logical character sequence itself is unchanged.
| [reply] [d/l] [select] |
| [reply] |