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.
That's great if you're the one running the editor and doing the editing.
What's not so great is when you give a co-worker a bash script, and they open it in Notepad, and then complain to you about all the extra spacing -- forcing you to waste a ton of breath explaining why it's not a problem with the text file, but an issue with their editor.
I once had to send a developer at my employer a SQL script intended to be run on Linux, and they did just this. It was unbelievable how long it took me to finally convince them that Notepad was the issue. And it wasn't just the double-spacing; they early had a fit because the file showed up as "ANSI" encoding in Notepad, whereas the spec said the file had to be UTF-8. So not only did I have to convince them (with lots of references) that Notepad was rendering CR/LF as two lines whereas UNIX systems treat them as a single line ending pair, but then I ALSO had to waste a lot of time convincing them that not only is there no such encoding standard as "ANSI" (a very long-standing bug in Notepad Microsoft has never got around to fixing), but that ASCII and UTF-8 are identical for values between 0x00 and 0x7F (which every byte in the document were within).
It was extremely annoying, because even with lots of links to references as to why they shouldn't be using Notepad for UNIX text files in the first place (and why you can't trust its encoding field), in the end I couldn't convince them. Our DBA eventually had to tell them the file was just fine as-is. And sadly, this wasn't the first person I've had this problem with.
As such, as a non-Windows user I'm rather happy for this change. I can't believe how many developers I run into who have no notion of line termination or the actual details of encoding standards, and who simply trust whatever Notepad tell them. Hopefully it will save me some aggravation in the future.
Yaz
Wake me up when windows can read EXT4 filesystems, I mean it has only been around for 15 years, is an open standard which could easily have been coded for, and it would be just common sense to do so. Meanwhile linux has been able to read NTFS/FAT/FAT32 for 20+ years.
But oh yay, linebreaks, lookit all that progress..
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.
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).