After reading your update:
I have encountered a situation where the output of Data::Dumper cannot be incorporated in a script to restore the original data, specifically where a string contains the sequence ^M^J and $Useqq is unset. (Note: this arises in my work because I have packed numbers in a large data structure, and on a few occasions the packed sequence happens to include ^M^J as a subsequence.)This should "just work", but you should use binmode() on a filehandle that you intend to read/write binary data to.
The issue arises because perl seems to have a "friendly" way to handle DOS files on Unix platforms. My guess is that at a really early stage of reading the script file, ^M^J is translated to ^J, presumably before perl is even parsing the input.Perl does no such thing (edit: on unix). However, writing "\n" on a non-binmode()d filehandle on windows will write a return/linefeed pair and vice versa on reads. On (most?) unixes, there is no difference between binary files and text files.
Obviously, it is ignoring the single quotes in this example, since the single quotes should suppress any interpretation of the input. (Note that I realize this is generally a desirable behaviour, so I think the bug is with Data::Dumper, not with how files are read.)Your example simply fails to demonstrate anything like that since you're not reading/writing any files. The output of Data::Dumper is correct, as me and others have already pointed out to you.
Note also that, as my script shows, this is not a problem when we use eval on the output of dumpSo Data::Dumper is in fact working correctly.
..., but only when the code is saved to a file a compiled back from the file. (Unfortunately for me, I wish to save the dump to a file for frequent reuse, so that doesn't help me much...)
And you're not showing us how you're reading/writing that file. I strongly suspect the error is somewhere in the code you're not showing.