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?
By "Mac OS", they mean versions of Apple's operating system prior to version 10.0.0
By "macOS", they mean all versions since (and including) 10.0.0.
(Apple renamed Mac OS X to just "macOS" a year or two ago, to better align with "iOS", "tvOS", and "watchOS" naming, as well as to move away from marketing the OS as "version 10", which they had already done for over 15 years).
To confuse matters somewhat, early versions of macOS (OS X) could run Mac OS software that used the old-style CR-only line terminator, so the line demarcating the change isn't exactly clean.
Yaz
'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,"'
You cannot be serious, what professional developer in his right mind would use Notepad?
Yeah, but then.. Notepad++
I don't know whether it handles Mac OS files, but Unix text files open just fine in Wordpad (which like Notepad is part of every Windows installation).
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.
Which line endings should I use when writing on the wall?
-- Make America hate again!
Is that edit.exe -- the console-based editor that came out with DOS 5.0 -- *did* support UNIX EOL. Go figger.
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..
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.
suddenly it got really cold down here for a moment
I call bullshit. How often do you really script something robust in 10 minutes? Do you have proper error handling, have you considered the edge cases, what about notifications of failure and logging output? It can take hours.
For one-off jobs a shitty little brittle 10 minute script is fine, but for something of high importance 10 minutes is usually not enough.
Personally, I don't see speed as the primary benefit... reproducibility is what I care about. I can spend 10 minutes doing a daily task... or I can spend an hour creating a script to automate that. After 6 days, the script will have paid for itself... after that it's all benefit to me.
So please... stop with the fucking dishonesty. It's not necessary.
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.
Millions upon millions of MS Windows admins 'stuck' with Linux systems?
It's not called 'stuck' when you are too stupid to learn how to do your job which includes managing Windows, Linux, BSD, various router and switching platforms, etc... The word you're looking for is 'incompetence'. Millions upon millions of *incompetent* MS Windows admins don't know *how* to work on Linux systems....
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).
Look, if you want to emulate ancient technology, you'd also better make sure that if you only send carriage-return, your emulation should smear the next character across the paper about 40 positions to the left of the prior character, and that every character past 72 should overwrite that 72nd position, getting darker and darker until the ink starts to spread. And your terminal emulator should make a terrible racket with every printable character, which by the way, only included UPPERCASE letters and run at 110 baud (10 characters per second, 11 bits per character - an extra stop bit because it needed that extra time, too).
ASR33s needed carriage-return, followed by line-feed because it took 200ms to get the carriage brought back to the left margin, slamming into the dashpot to cushion the blow, with the small metal arm carefully adjusting the size of the air hole to make the dashpot as close as possible to critically damped.