Slashdot Mirror
Windows Notepad Finally Supports Unix, Mac OS Line Endings (theregister.co.uk)
Microsoft's text editing app, Notepad, which has been shipping with Windows since version 1.0 in 1985, now supports line endings in text files created on Linux, Unix, Mac OS, and macOS devices. "This has been a major annoyance for developers, IT Pros, administrators, and end users throughout the community," Microsoft said in a blog post today. The Register reports: Notepad previously recognized only the Windows End of Line (EOL) characters, specifically Carriage Return (CR, \r, 0x0d) and Line Feed (LF, \n, 0x0a) together. For old-school Mac OS, the EOL character is just Carriage Return (CR, \r, 0x0d) and for Linux/Unix it's just Line Feed (LF, \n, 0x0a). Modern macOS, since Mac OS X, follows the Unix convention. Opening a file written on macOS, Mac OS, Linux, or Unix-flavored computers in Windows Notepad therefore looked like a long wall of text with no separation between paragraphs and lines. Relief arrives in the current Windows 10 Insider Build.
Notepad will continue to output CRLF as its EOL character by default. It's not changing its stripes entirely. But it will retain the formatting of the files it opens so users will be able to view, edit and print text files with non-Windows line ends. Microsoft has thoughtfully provided an out for Windows users counting on the app's past inflexibility: the new behavior can be undone with a registry key change.
Notepad will continue to output CRLF as its EOL character by default. It's not changing its stripes entirely. But it will retain the formatting of the files it opens so users will be able to view, edit and print text files with non-Windows line ends. Microsoft has thoughtfully provided an out for Windows users counting on the app's past inflexibility: the new behavior can be undone with a registry key change.
All users caring about line endings had probably migrated to Notepad++ 10 years ago, right ?
Notepad is a small simple text editor that exists because occasionally you might need to edit some text files (typically for config files or something). These will be in a Windows friendly text format. It doesn't pretend to do anything remotely sophisticated.
If you want to do something more complex then download a non-minimal text editor. There are loads available for free.
You want the carriage to return and the paper moved up by one line, not print over the last line (CR only) or continue at the current position one line down (LF only). Imagine that, Microsoft doing something correctly.
Or will this be backported to Windows 7?
Yeah, but then.. Notepad++
It's also Windows 10 Bleeding Edge Edition only, so it's still not going to help that many people.
And mAcOs is kinda lumpy, while MacoS is either a suspension bridge or a Filipino meat dish.
Is that edit.exe -- the console-based editor that came out with DOS 5.0 -- *did* support UNIX EOL. Go figger.
CR: return to first character of the line.
https://en.wikipedia.org/wiki/...
LF: jump to the next line.
https://en.wikipedia.org/wiki/...
Perhaps you should read those articles (I've only verified the relevant parts so normal Wikipedia cautions apply), understand where the control characters came from, what they were used for and why there are different line endings out there? No "properly" about this.
That it have taken this long for MS to change something this trivial is strange though. Guess they always assumed nobody use notepad?
...in after-hours trading.
Zaelath noted:
Yeah, but then.. Notepad++
Personally, I've used Alan Phillips' Programmer's File Editor in place of Notepad for almost 20 years now.
MS made it harder when they killed off support for the .hlp helpfile format, but there are ways around that - and, in addition to a pretty useful feature set, the program IS free, after all ...
Check out my novel.
Mac OS 1 through 9 use the same newline as ProDOS on the Apple IIe: $0D.
Mac OS X 10.0 through 10.11 and macOS 10.12 to present use the same newline as UNIX: $0A.
Traditionally, MS-DOS and Windows have used the same newline as Digital Research's CP/M: $0D $0A.
The $0D $0A sequence dates back to the Teletype Model 33 terminal, one of the first terminals to use ASCII. It could process a carriage return ($0D) and a line feed ($0A) in parallel, but because a return took longer than a line feed, computers sent the return first, then the line feed, then a split second of pausing before the next character so that it wouldn't get smeared across the page during the return. If your Model 33 had the optional ASR paper tape drive, you might have had to use the delete key to insert the pauses yourself.
UNIX relied on terminal drivers to convert a newline to whatever sequence a particular terminal needed. CP/M just encoded what the terminal expected directly into an application. MS-DOS was originally a clone of CP/M (and DR-DOS was forked from authentic CP/M), and Windows was originally a GUI shell around MS-DOS. Though MS-DOS 2 was sophisticated enough to use these sorts of drivers, it had to remain compatible with applications designed for the much more CP/M-like MS-DOS 1.
Let's be fair here. The correct implementation of a new line in a text file *IS* CRLF. It is the format you need to send a printer to print the text. A single CR would just print all the text on a single line overwriting itself over and over, and a LF would make the text look like a staircase (until it ran off the side of the page). CRLF is therefore the correct way to end lines in a text file (or LF+CR which actually makes more sense, but I wasn't consulted when the standards started). Seriously, just go read any manual that describes the ASCII control characters and there will be no doubt left in your head about what SHOULD be the correct way.
Linux got it wrong because it copied it from Unix. Unix got it wrong because it got copied from Multics (some of the original devs working on Unix were also devs on Multics). Multics (most likely) got it wrong because it was a bad performance hack (using a single byte to end lines is easier).