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 ?
Wow. How are they different?
http://michaelsmith.id.au
For years I've used notepad just for this reason: remove and drop all unix lineendings. That way I knew I never ended up with a mixed-line ending document.
Ubuntu is now an officially supported part of Windows.
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?
It is just odd that they would leave this out forever on purpose and then suddenly fix it. It has been literal decades, and the absence was obviously malicious.
Cloud is king and the writing is on the wall. You don't take you lead architects of core products unless your business strategy is changing. This is just another sign of the inevitable.
My ism, it's full of beliefs.
who cares?
Millions upon millions of MS Windows admins 'stuck' with Linux systems? It's actually kind of funny to watch them work, they are so used to point-n-click snap-in GUI interfaces that most of them don't even know how to write a script. Recognise a Windows admin worth having a conversation with by the fact that he scripts most of his work using VB or C# rather than sitting there for hours pounding a mouse button working a GUI management tool to do stuff a script can do in 10 minutes.
Exactly.
I'm not going to suddenly start editing text in Windoze. I mean, I'm not going to complain that they started actually ending lines properly, it only took forty-ish years, but they finally figured out how to do it.
Meanwhile, TeachText became SimpleText became TextEdit. The Macintosh user interface evolved through many generations. And now, finally, in 2018, MicroShit figures out how to do what they should have been able to do in 1984.
Idiots.
'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.
This is geared at people working with mixed deployment systems on Azure. And it's great. Honestly, this has been my most wished for feature in Windows for a long, long time.
Drop the negativity - a good and useful thing has just happened. Thanks.
MS write (or.. wordpad?) always supported it and came with windows free so it was never a big deal.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
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.
We already knew this, but it became painfully obvious with various rags (including el reg) gushing about how "powershell" was teh bestest thing evar... conveniently forgetting it's only about as many years behind Unix, and even Unix was merely following in older systems' footsteps.
So if this isn't sheer head-up-butt incompetence, then it's malice: They're banking on having their users have no memory. But, you know, that's not quite how it works. Not with compatability features. But we can assume that the current crop of editors are indeed redmond fanbois, possibly paid shills, for finding ever newer ways to point out the fancy polished shine on this turd. It still doesn't really entice me, as the reasons I ran away from redmond and its crap software are still entirely too valid.
I use WinVI as a replacement for notepad. Standalone, small, starts immediately. Works like Notepad, but you can press escape to go into VI mode. And the handling of LF/CR is superb.
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..
this app can break
Even better... EditPad!
Incipiamus, fratres, servire Domino Deo, quia hucusque vix vel parum in nullo profecimus.
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?
Yes this is probably yet another advantage due to the Linux subsystem and therefore (indirectly) Linux.
You are a modern human right? So you use Unicode, right?
U+2029
Lots of people use notepad. More likey they didn't want to accommodate Mac/Linux files, just like they have always done. This small change, to me, actually represents a hugh change in direction for MS especially on top of the Linux on Windows work they have done and their cloud linux stuff. Big changes ahead, lets just hope they don't get to the extinguish step.
Keep up the good work. Eyes waiting for "not trying to format any non-win partition on a drive"
...in after-hours trading.
who cares?
All they have to do now is replace the rest of their OS. And also get notepad to not output CRLF, because we don't need that in the world.
I mean if they want their OS to just be for games great, but anyone that can make a choice is selecting anything else. It's a horrible environment to get real work done on.
Because Notepad++ is a GPL open source project. It can't be bought.
$50 for an inferior editor is even better?
Being able to handle large files by NOT trying to load a huge file into ram and only noticing after two minutes or 10 that it fails will probably take another 40 years.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
suddenly it got really cold down here for a moment
Do you have a moment to talk about our lord and savior Sublime Text?
"vi -b" to see the ^M end of line character and ^Z end of file characters of windows text files under *nix.
>/dev/null 2>&1
If it's good enough for RFC 5321, it's good enough for me.
To be honest, the CR + LF line ending is closer to be a standard for text interchange than any other combination of CR and/or LF. Many IETF RFCs mandate the use of CR + LF.
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.
Guess they always assumed nobody use notepad?
Or maybe they are planning on screwing up wordpad even more. :-/
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....
Vim is the fastest editor I know of. Sure, you need to learn some, but it's worth it.
There's your problem. Windows admins don't give a shit about being fast, efficient, or knowledgeable about all things IT-related. They learned how to point-and-click on their mom's computer at age 6 and that's why they will always recommend Windows--they don't have to be bothered to learn something new.
> Recognise a Windows admin worth having a conversation with by the fact that he scripts most of his work using VB or C#
powershell. they should be scripting in powershell these days, which is kept up to date, has tons of built in functions and available modules for working in AD and just about anything on a wdinwos computer or server already available, and can take advantage of .Net libraries so you dont have to develop in c# to get something that powershell doesnt have as a native cmdlet. VB still has its uses, but the sort of stuff my coworker does in VB is way easier in powershell much of the time. I'm not saying there is no use for c# scripting, but powershell is where it's at.
I am a windows sysadmin who had a little linux background and uses a ton of powershell in my day to day work. there is some weird stuff MS is still behind on for no-good-reason, serer 2012 and 2016 resolved some of those things, but powershell gets a lot of attention from them
By and large, language is a tool for concealing the truth. -- George Carlin
> It's a horrible environment to get real work done on.
this is sort of ridiculous, we are stuck on windows 7 at work and I can get all of my work done without an issue--my last job had 8.1 which i liked better, what do you really get out of linux that is so great? I got frustrated with linux a long time ago and have never looked back--to each his own, right? windows is not perfect, and *nix has had several features MS has been stupid slow to incorporate, but come on, to act like it is worthless is just silly at this point.
By and large, language is a tool for concealing the truth. -- George Carlin
Why does this need to be disabled ever? How is it ever better to ignore obvious line breaks?
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.
Ubuntu Server, yes. Anything that relies on the presence of an X server, not quite yet. WSL users trying to run GUI apps have to obtain an X server elsewhere, which usually means a decade-old copy of Xming.
I just heard that Windows notepad tried to replace MS-DOS edline (line editor https://en.wikipedia.org/wiki/...), but failed as edline is still in Windows 10 !?
Don't worry, it's just part of their plan to make Windows more Linux-friendly, until one day they'll nuke all dual boot systems from the orbit "inadvertently" with a software upgrade, only to tell people they need not to worry, since they can continue to use Linux from their Windows partition. :-)
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).
I'd like to see a menu option that lets the user specify what type of line-ending is wanted. Upon making the choice, an open document would be automatically given a search/replace pass, to change all line-endings to the specified type.
Tis the year that M$ embraces Linux...
It is the year of Linux on the Windows Desktop.
M$ is now extending its support for all things GNU / Linux in a bid to extinguish GNU / Linux once and for all.
Yep, that was the original idea of ASCII control codes to control teletypes and teleprinters over serial communication links.
A fraction in ratio notation, such as 1/2, is assumed to be exact unless specified otherwise. A decimal, on the other hand, often represents an interval of real numbers based on significant figure conventions. For example, 0.5 means "anything that rounds to 0.5", namely the interval 0.450 to 0.550, and 0.50 means "anything that rounds to 0.50", namely the interval 0.495 to 0.505.
Unix is not a text editor.
A UNIX system includes the vi application, which is a screen-oriented text editor. The standard specifies its behavior.
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.
Notepad++ has that. ...
Edit -> EOL Conversion ->
Maybe you wanted that in Notepad?
"I'm so moist I'm sticking to the leather." -Kermit the Frog on The Late Late Show
I'm stuck between, "this is a joke, no one would do that," and "who would make something like that up?".
You might want to improve your toolset, perhaps with software from the current millennium.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
I gave up on convincing people of things.
I will simply state something repeatedly... like "csv files are not Excel files. They are text files with comma separated values." Just because nearly EVERYONE uses Excel to view them, sometimes with terrible results because then they SAVE them in Excel which can change the data, doesn't make them Excel files.
It's kind scary how things like that just become the de-facto standard. Then you get someone - a developer - trying to open and edit a 2MM row csv with Excel. While the developer was waiting minutes for the file to open in Excel... I opened it in vim, made the edits, zipped it up, and emailed it back to him. And people still think I am backwards for using the command line.
My beliefs do not require that you agree with them.
Yeah, but then.. Notepad++
I prefer PSPad myself... but I'm a network engineer, not a programmer...
I needed something that could handle both large log files and UNIX formatting. Even with this fix, Notepad still wouldn't work for me because of it's file size limits.
It is worthless from my perspective. Literally everything I do or use, if it works at all, requires a ton of work-arounds or bloat, or custom support from vendors who will never provide it.
I suppose it depends on what you do, but browsers work fine everywhere, and I don't really need word or excel, i work for a living.
Yeah. They have a lot more things to support before I stop throwing up in my mouth whenever I have to use notepad.
I object to power without constructive purpose. --Spock
Registry change? WTF!?
I object to power without constructive purpose. --Spock
I used Wordpad for viewing text documents instead of Notepad, because Wordpad would let you wrap lines. I didn't use either to actually write text docs though. I did go to notepad+ a couple years back, but it does a lot of things I don't like, but it's much better as a "default" application to read text files.
Microsoft has been steadily removing more and more user options from menus. They seem to fundamentally dislike the notion of user customization. Sometimes those removed options go to the registry, but they also remove registry entries as well.
Ha. I know RFCs are treated as "standards" but those are only standards through general grudging agreement. Many of them came into existence with very little feedback, some were modified by later RFCs, etc. I take them with a grain of salt. My guess is that requirement is there just so that some less-than-stellar programs would work.
A lot of systems were written at a time when printers that didn't all work the same way and display terminals that did not all work the same way, so they would add a bit of translation when printing files, converting the text format to a printable format. Ie, read a record, send to printer, add CR+LF, repeat. Ie, the file didn't have the same format as the protocol needed to send the file and display it properly on a printer. There were tons of file formats out there, the "plain array of bytes" used on Unix wasn't all that common. No one could point to just one format and say "this one is correct all the others are wrong, without sounding like it was proselytizing".
When microcomputers came along later, most affordable printers had settle into a single way of doing things with CR and LF, so the micros found it easy to just copy a file verbatim to a printer without needing a file. In other words, the file and the protocol were merged, somewhat out of ignorance perhaps, or maybe for convenience.
These were telegraph codes originally, later standardized in Baudot codes (1900ish). CR and LF were separated from each other for practical purposes. CR took a long time for the carriage to actually return, but LF was fast. So you could send CR+LF+LF to do double spacing, or send lots of LFs to put in more gaps. Sending a redundant CRLF when only an LF was needed was wasteful, slow, and expensive.
So there is no "correct" implementation. A file format does not need to have a printable representation internally.
Thank heavens the abysmal DOS way of using ^Z was ditched though.
GPL means they would need need to pay for it, but they would probably want to get the developers on board (not necessarily employed).
There are many other free utilities that they could add. WinDirStat is one. 7zip another. Very cheap ways to add value to the base O/S with minimal effort or risk.
LF must come after the CR because it takes more than 100ms to return the carriage. The LF can happen while the carriage is returning. But if it is beyond about column 40 then 200ms is still not enough, so you need to add a NULL.
Those machines really flew at ten characters per second. Marvelous engineering.
Well except that baudot didn't have a line feed character. It had a "line" character which both returned to the beginning of the line (like carriage return) and advanced the paper (like a line feed). Line feed by itself didn't go back to the beginning of a line. For all the terminals and printers I know of, if you sent it "abcdef", it would turn out like this:
abc
def
As it was defined to do. And that's why line feed by itself is just wrong. That's also why character code 10 in every ASCII chart including the first one defined in 1963 is called "line feed", not "line". Line feed has a very specific definition, and multics/unix/linux misused it if you actually want to be able to call your text files "ASCII". It either conforms to the ASCII standard or it does not, and having a line feed character act line a CRLF simply does not.
But I agree with the ^Z (EOF) character. I can't count the number of times that copy {src} {dst} landed up truncating a binary file on me because I was too lazy to specify the /b option to tell it that it was a binary file and not stop at the first EOF character.
Erm.. Yay slashdot for eating thing that look like HTML. That was supposed to be "abc^Adef" would turn out like:
abc
def
This is incorrect. Quite a few terminals, especially line printers and video terminals, interpreted LF as moving to the start of the next line.
It was teletypes that did the unusual move straight down. This was done in order to hide the slowness of the mechanism for returning the carraige. Having to send a LF after a CR meant that there was an extra character time to handle the CR and get the carraige all the way to the left before printing.
Dec in particular used Teletypes as cheap terminals, leading to the CR+LF behavior. CP/M was strongly influenced by DEC and from that you got MSDOS and Windows. Other systems (ie Multics, but also all other mainframe systems) used as single character for newline.
And the BOM breaks every one of those magic numbers by being there instead of them, stupid.
This is incorrect. LF was pretty useless for positioning because the machines lacked any method of moving the printhead to the left (other than CR). Backspace did not work.
The reason LF worked this was was to force data to waste the time of 1 character after sending a CR. If LF returned to the left and moved down (as it did on MANY devices) then cheap ones could not do this fast enough to be able to print the next character.
I could be wrong, as much of this was before my time, but I don't recall a single printer that interpretted LF as moving to the start of the next line, and a cursory examination of terminfo (the most complete database of terminal capabilities that I am aware of), and having written a couple dozen terminal emulators myself shows that the vast majority does exactly what I said.. "cr" is defined as the ASCII CR character, cud1 is defined as the ASCII LF character, and nel (new line) is defined as the combination of ASCII CR and ASCII LF: .kbs=^H,
dumb|80-column dumb tty,
am,
cols#80,
bel=^G, cr=\r, cud1=\n, ind=\n,
unknown|unknown terminal type,
gn, use=dumb,
lpr|printer|line printer,
OTbs, hc, os,
cols#132, lines#66,
bel=^G, cr=\r, cub1=^H, cud1=\n, ff=^L, ind=\n,
glasstty|classic glass tty interpreting ASCII control characters,
OTbs, am,
cols#80,
bel=^G, clear=^L, cr=\r, cub1=^H, cud1=\n, ht=^I, kcub1=^H,
kcud1=\n, nel=\r\n,
vanilla|dumb tty,
OTbs,
bel=^G, cr=\r, cud1=\n, ind=\n,
Sending CR+LF to a terminal that did both for LF was harmless, which was why the dumb definition does that. Most of these terminals had a option to switch the behavior due to the popularity of DEC operating systems (as they supported Backspace it was actually possible some software relied on LF going straight down, earlier terminals did not interpret backspace so going straight down was nearly useless). I know VT100s did, I think VT52 did with a dip switch. As the computer could not know which way the terminals were set, sending both was safer.
Auto backup in case the system crashes/restarts.
It's sad that it's newsworthy the Microsoft finally makes a small improvement to a 30 year old piece of shit app. Fuck you Microsoft.
hmmmm, I try to go for a current model so you can get parts for it. I mean it's cheaper if it's end-of-line but it's much harder to get parts.
-- Make America hate again!
clever sig you got there.
My ism, it's full of beliefs.
That actually explains a lot. Every once in a long while someone comes along and makes a truly insightful post and I remember why I still come here. Thank you for that.
WordPad has always been able, and available.
How is this a slashdot-worthy notice?
Self-importance and self-indulgence is the root of ALL evil.
Back when this mattered, it was standard to include a DIP switch settings on the printer which selected between various behaviors in response to CR and LR.
That's a nice argument, but taking a step back from the origin of these character codes, which aren't really that important except from the point of view of a history major, it simply doesn't make any sense to use two characters to denote the end of a line in a text file. Doing so only raises the question of what either of those characters by themselves ought to mean, to which I can't think of a sensible answer.