XYplorer Beta Club

You can test it with latest beta and the attached file (it's supposed to be the header of an mp3 file).
Correct dump is XY wrongly reports as a result of

No file attached.

PS: I solved by using meanwhile

So, false alarm, right?

I found a way that gives the correct result (call it a workaround), but the bug is still there.

I don't think there is the bug. These are the bytes: And it is correctly returned by: That's no workaround but correct scripting.

Your other code makes the wrong assumption that the file is a Unicode text file and therefore decodes it into a text string according to your locale. Makes no sense with a binary file.

Ah ok, thanks for the explanation. And I'm relieved now, I encountered this behaviour during a backup-related scripting session and you can imagine my reaction to seemingly corrupted data!

Just thought a bit about it - and don't understand.

The string supplied is just a set of some bytes - to show it in hex (dump 'raw') there should be no dependency to unicode, isn't it so? As I think the left = hexadecimal part of the dump has to show exactly the hex representation of the supplied string of bytes. No matter if it's to be interpreted as character, unicode, binary, or whatever. For me this is the reason for a hex dump: see, what's there.

Or do I miss something?

The string supplied is just a set of some bytes

A string is a locale-sensitive *interpretion* of a set of bytes.

admin wrote:

The string supplied is just a set of some bytes

A string is a locale-sensitive *interpretion* of a set of bytes.

We are talking about a (hex) dump, and the bytes to be dumped? I think the dump has to show what is, not not what can be interpreted.
To exaggerate: the dump of the binary number 0x'007b' would not be '31 32 33'.

The interpretation may apply to the right = alphanumeric column, or to the output on inverse dump.

readfile returns a locale aware string. hexdump does what you tell it to do with it (how to interprete it).