Skip to content
Prev 277054 / 398506 Next

Generating the Ctrl-M character

No need to get defensive... I couldn't tell whether you remembered the details. This is starting to go OT, though.

As to handing "\n" as expected, in the context of generating text files for their native platforms they do act "as expected".  However, in the context of people writing binary characters in a file in an attempt to make it suitable for some other platform, munging can happen, and people can be surprised by the results if they don't get the whole picture.

Specifically, AFAIK "\n" is always stored as a single character (LF) in memory on UTF8 or ASCII systems. On Windows, when that character is written to a text file a "\r" is written just before it, creating the expected end-of-line marker for a text file on that OS.  On the old Macintosh operating system a  lone "\r" was the EOL marker, so "\n" was automatically translated to "\r" (but not on OSX, which uses UNIX conventions). From the perspective of the person working with native text files, this makes things "just work". From the perspective of someone trying to obtain a particular but pattern in the output file this amounts to "munging".

The C programming standard library includes the concept of distinguishing between text files and binary files just so this "native adaptation" can occur or not, depending on the desired behavior.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
--------------------------------------------------------------------------- 
Sent from my phone. Please excuse my brevity.
David Winsemius <dwinsemius at comcast.net> wrote: