0

On a fresh install of Windows 11, running Strawberry perl, I'm debugging a script that parses the output of du64 (disk usage). It worked on Win 10 with ActiveState perl.

To debug, I first checked du, without parameters:

use strict;
my $prog = 'du64.exe';  # Sysinternals
my $st = qx( $prog );  # backtick
for my $i( 0 .. 6 ) {  # first few bytes of output
    printf "[0x%02X] ", ord( substr( $st, $i, 1 ) );
}
print "...\n";

Output: [0xFF] [0xFE] [0x0D] [0x00] [0x0A] [0x00] [0x44] ... (Note FFFE is the byte order mark associated with UTF-16LE, and the perl Encode module confirms this encoding.)

Expected: [0x0A] [0x44] [0x55] [0x20] [0x76] [0x31] [0x2E] ...

kitchin
  • 774
  • 6
  • 9

1 Answers1

0

Answer: Sysinternals had never run on this machine, and it needed to pop up a license acceptance window. After that one-time edge case, everything worked as it had for years on my old machine.

Running du64.exe without parameters via perl backtick had an exit code I didn't check. But calling it with parameters, such as du64.exe foo, had exit code 256. Then running it with the parameter at the command line without perl popped up the license acceptance window. So the Answer.

After that encoding returned to normal, as seen by perl anyway, and there was no BOM.

The Windows code page command chcp was irrelevant.

Win 11 has a beta feature called "Use Unicode UTF-8 for worldwide language support" but I did not experiment with checking it on. I've read it is default on, but it was off on my machine. Probably irrelevant.

Windows version, perl vendor: probably irrelevant.

It's an edge case, arguably bug, in Sysinternals popping a window, or failing to do so and exiting on no license.

kitchin
  • 774
  • 6
  • 9