On Fri, Jan 20, 2017 at 6:06 PM, Rugxulo <rugx...@gmail.com> wrote: > On Thu, Jan 19, 2017 at 5:51 PM, dmccunney <dennis.mccun...@gmail.com> wrote: >> >> At one point, I had to insert a step in a *nix script that generated >> and emailed nightly reports. The recipients would get them as >> attachments on Windows machines, and double click them to read them, >> which by default invoked Notepad to display plain text files. Notepad >> was *stupid*. It saw the LF, so it advanced a line, but it *didn't* >> see the CR, so it didn't home the cursor before displaying the next >> line, and the result was a stair step effect.when the file was viewed. >> I had to call a Unix2DOS utility to adjust the file to CRLF line ends >> before emailing it. > > In fairness, most people don't use Notepad. Or at least I never do. > It's very simplistic, so it's not what I'd call "programmer friendly". > Almost anything is better except in a pinch. (Remember the old Win9x > days when it wouldn't even handle bigger than 64 kb?) Honestly, I > think Notepad was originally just a demo of the (then-new) Win 3.x UI > (or thereabouts).
This was a corporate setting, and most people used what came with the standard Windows image we deployed. The default was Notepad as the plain text editor, and that was what got invoked if you double clicked a text file attachment to an email in Outlook. Notepad wasn't what *I* used, but I was IT staff and had greater freedom about what I could install. These days, I think the accurate statement is "Most people don't use a text editor." >> *nix was actually more of a problem than Windows. Most things in *nix >> treated a CR as a white space character and didn't care about them, >> but a few things had issues. The problems on either OS tended to be >> things that displayed/edited files. Notepad on Windows had the >> problem noted above. *nix tools displayed ^M wherever a CR was >> encountered, which was annoying. > > Under vi, you can obviously do ":%s" and then "^V^M" or such. Yes, and I did. But who needs the annoyance of needing to? I did EOL conversions of files I moved to *nix from DOS/Windows to avaid it. >> It's probably a good idea to sanitize FreeDOS text files to have CRLF >> consistently, but under DOS and Windows I installed editors and file >> viewers that understood LF as EOL char and did the right thing so I >> didn't have to care, and deliberately saved text files with LF as EOL >> character so I could move them to *nix without caring. > > There's all kinds of caveats and quirks in many tools. > > Even MS-DOS EDIT would almost always forcibly convert tabs to spaces > or some such behavior. Which is only bad with the Makes that can't > handle whitespace instead (which ironically is very few, yet the whole > tab issue persists anyways). I remember trying to find out why a make was failing, and tracing to it to of spaces instead of tab characters. This was Unix make as supplied with AT&T SysV, but I think other makes are better about that now. > Even some files didn't end in a linefeed at all, so that too would > confuse some tools. The fix, at least on *nix, was "echo wq | ed > myfile.txt". I don't recall encountering that quirk, for which I'm grateful. >> How many things available as part of FreeDOS *do* have problems with >> LF only EOL markers in text files? > > AFAIK, anything compiled by Turbo Pascal (unless the programmer > manually went out of his/her way to adjust accordingly). Various other > old tools too (e.g. FST Modula-2, maybe TC 2.01 too), but most good > and popular ones don't care, e.g. DJGPP or Free Pascal. Okay. Noted for future reference. Thanks. ______ Dennis ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
