Talk:Newline

message: The article currently describes only the usage in text files/flat files. Somebody should add a section about Text processing/Desktop publishing as well. User:ScotXWt@lk 12:25, 17 December 2017 (UTC)
thread_title:  Flat file vs. Text processing / Desktop publishing 

message: Please discuss merging this article with End-of-line in the "Merge?" section. — Preceding unsigned comment added by Chris Chittleborough (talk • contribs) 06:54, 6 September 2006 (UTC)
replies: text: Not that there's anything to discuss any more, as the merger has been done. Guy Harris (talk) 06:23, 23 August 2017 (UTC)
thread_title: Merge

message: There are examples how sed works with line endings. Those are examples which work only with some variants of sed, but require a non-posix compliant sed (but like available on most linux). E.g. http://www.grymoire.com/Unix/Sed.html#uh-nl - the variant described here e.g. don't work with the versions shipped with MacOSX.  — Preceding unsigned comment added by 195.4.206.111 (talk • contribs) 20:28, 22 September 2009 (UTC)
thread_title:  Examples to convert line endings 

message: AIX is a Unix variant after all. Does it really follow OS/360?? Yaron 21:47, Aug 2, 2004 (UTC)
:OS/360 and Unix have nothing in common except that OS/360 was developed by IBM before Unix existed and AIX is a distribution of Unix from IBM. Windows is more like Unix than OS/360. Sam Tomato (talk) 07:36, 24 January 2017 (UTC)
thread_title:  AIX 

message: Would be nice if this article included or linked to methods for converting the various formats since this is still occasionally problematic.  I doubt my long-standing method of running a sed command from vi involving CTRL-V CTRL-M is optimal...  --16:13, 17 May 2005 (UTC)
thread_title:  Solutions 

message: When you use programs like diff to compare the text in two file which uses different line endings there are some ambiguites.
Unlike most modern text editors the original unix diff program and GNU diff seems to think that the files differ even though the content except for the line endings are the same.
This makes porting between for example GNU/Linux and MS Windows more difficult.
The http://www.GnuWin32.org/ port of GNU utilities have changed this behaviour so that diff does not care whether CR/LF or just LF is used as the line ending.
This seems useful to me and I think that just as the text editors the diff program ought to think of line endings as just line endings and not care about its actual format when comparing two files.  — Preceding unsigned comment added by 83.249.205.211 (talk • contribs) 19:01, 24 September 2005 (UTC)
thread_title:  Using the diff Program with Different Line Endings 

message: It's true Notepad doesn't understand LF as "new line". But instead of using edit (and advising Windows users to use old text DOS program) I'd recommend Wordpad. It opens files greater than 64 KiB (Notepad can't do this) and easily converts LF to CR LF with just open/save. Wordpad is part of standard Windows distribution and is for sure more Notepad-user-friendly than any DOS tool. I'd change the page myself, but, as can be seen in this text, my English skills won't suffice :)
: Hm, I don't have wordpad installed on my windows xp... maybe I manually de-selected it during the installation, I don't really remember. Maybe we should just mention both Wordpad and EDIT then. --K. Sperling (talk) 13:20, 1 October 2005 (UTC)
replies: text: From the command line (Windows Vista may also apply to other versions such as XP) WordPad is executed by the command "write" and there is no "wordpad" command. The advice above about using WordPad in Windows to convert line endings is valid and useful but should include mention that to execute WordPad from the command line it the user needs to enter "write" as in C:>write sample.txt otherwise it may appear that WordPad is not installed. --Pdegregorio (talk) 12:40, 7 May 2009 (UTC)
thread_title:  Conversion using Windows Notepad/Edit? 

message: The overwriting example given like this:
  cat filename | tr -d '\r' > filename
only worked because both cat's own buffering and the in-kernel pipe buffer meant that the beginning of the file could be read and eventually given to tr before the shell would truncate it and setup it as tr's STDOUT. You would lose the rest of your file if it was larger than those buffers (usually no more than a few tens of KB). It doesn't work because the file is truncated before you begin to overwrite it, but it might have worked somewhat if it were just overwritten since the new chunks would only be 1 char larger or smaller per-line and the buffering would have allowed enough slack to prevent unread parts from being overwritten. But that would have been risky still. —Preceding unsigned comment added by 24.200.77.59 (talk • contribs) 
:True enough (depending on the OS and a bunch of other stuff, obviously). I've removed the useless use of cat. (Gee, that's a silly redirect, but it does seem to get used occasionally...) If some reader doesn't realize that infile and outfile must be different files on some operating systems, then that reader probably isn't going to be using tr to port text files between different OSes in the first place. There's no need to clutter the article itself with irrelevant technical minutiae. --Quuxplusone 06:06, 25 April 2007 (UTC)
thread_title:  Conversion utilities 

message: Does anyone know what conventions were used by Terminals like the VT100? I'm aware the IBM PC compatibles had ROM BIOS that converted the key code from what is now called the "Enter" key in to CR, Ox0D,CNTRL-M, but what did standard serial terminals send?
:Usually CR, but you could tell the terminal to send LF instead using an escape sequence. CWC 08:04, 5 July 2007 (UTC)
replies: text: They sent ^M, and required both ^M and ^J to go to the start of the next line. VT220's at least had a configuration option to make ^J act like both ^M and ^J, not sure about VT100.  —Preceding unsigned comment added by Spitzak (talk • contribs) 16:51, 13 October 2009 (UTC)
thread_title:  Terminal conventions. 

message: I have created a disambiguation page for line break and changed the link that redirects to newline from line break to line break (computing).  I also have a copy of this page saved in case anyone is looking for it, but I'm pretty sure it's just as easy to find now.  —Preceding unsigned comment added by Ark2120 (talk • contribs) 16:55, 18 October 2007 (UTC)
thread_title:  Disambiguation 

message: We encountered this issue while trying to svn checkin a Flash actionscript edited alternately on Mac OS X 10.4.10 with "Adobe Flash CS3" and "Adobe Flex beta 3", built on Eclipse. Adobe Flash CS3 saves with CR, while Flex save with LF only (the right thing for a psuedo-UNIX like Mac OS X).
Anyhow, just thought Adobe should be publicly flogged for persisting Mac OS 9 behavior well past its obsolence, and praised for moving in the right direction finally.  —Preceding unsigned comment added by 208.72.192.23 (talk) 01:08, 22 November 2007 (UTC)
thread_title:  some modern Adobe products still exhibit the obsolete Mac OS 9 linefeed behavior 

message: I added a bit about special handling of newlines during program execution to the "Newline in programming languages" section. It feels a bit wordy to me, but is the best I could explain it. Someone more gifted with English may want to clean it up. badmonkey (talk) 03:58, 18 December 2007 (UTC)
thread_title:  Programing Helpers 

message: Accessing modems using the AT command set instructions are terminated with a carrige return symbol. You can read this in Command and Data modes (modem) and Hayes command set. I have tested this also with minicom and an old POTS modem. Thence this should be mention but I'm not that good in english to edit an article in such a major topic. --84.156.100.251 (talk) 17:50, 20 March 2008 (UTC)
thread_title:  AT command 

message: In the bash and ksh93 shells the following will not work as '\r\n' will be seen as the string 'rn'.
 egrep -L '\r\n' myfile.txt # show UNIX style file (LF terminated)
 egrep -l '\r\n' myfile.txt # show DOS style file (CRLF terminated)
For these shells, one need to use builtin shell expansion $'word'
 egrep -L $'\r\n' myfile.txt # show UNIX style file (LF terminated)
 egrep -l $'\r\n' myfile.txt # show DOS style file (CRLF terminated)
The file command should also detect the type of EOL used:
 file myfile.txt
 > myfile.txt: ASCII text, with CRLF line terminators
Other tools permit to visualise the EOL characters like the following commands:
 od -a myfile.txt
 cat -e myfile.txt
 hexdump -c myfile.txt
--Ripat (talk) 13:51, 24 June 2008 (UTC)
thread_title:  End of Line detection 

message: Dear Sirs, I notice there are different ways to write a paragraph:
#No newline (\n) until the very end, maybe hundreds of characters along.
#Newlines every 80 characters or so. Then a pair of them at the end.
Please mention which format is inherently smarter. Jidanni (talk) 01:50, 2 February 2009 (UTC)
replies: text: Are you looking for ways to store multiple rectangular texts in a file? 2A01:119F:31B:5D00:CDA:B9B8:6D94:5EE (talk) 15:10, 22 September 2020 (UTC)
thread_title:  Inherently smarter 

message: I recently noticed that the export plugin of Excel for Mac exports txt files with CR only. Mayb this should be mentioned since it's a bad error source for programmers expecting LF and CR LF is all they need to take care of.
CatzHoek (talk) 20:51, 4 April 2010 (UTC)
replies: text: Please inform the Excel version number.Hyungjin Ahn (talk) 05:22, 1 January 2011 (UTC)
thread_title:  Microsoft Excel for Mac txt export =

message: Hi, 
I don't think that the section on one particular Microsoft product is relevant for this article. I am sure there are many more programs that have bugs / incorrect handling when it comes to newlines and this is not the place to document them. I suggest to remove section 5.1 and 5.1.1 Drdee (talk) 18:51, 3 June 2011 (UTC)
thread_title:  Delete section 5.1 (Microsoft product) 

message: Without knowing already what this article is about, I would not understand it at all. Currently the article begins with:
»In computing, a newline, also known as a line ending, end of line (EOL), or line break, is a special character or sequence of characters signifying the end of a line of text and the start of a new line. The actual codes representing a newline vary across operating systems, which can be a problem when exchanging text files between systems with different newline representations.«
# A link to character encoding should be there as well, to embed this whole thing somewhere (<- BTW, that article is also crap, prefer :de:Zeichenkodierung.)
# character (computing) should be replaced with control character
# For practical purposes one could bother to mention the most frequent issue: to encode a line-break/newline in a text file UNIX uses 0a, Microsoft uses 0d 0a.
# printing User:ScotXWt@lk 10:51, 16 December 2017 (UTC)
thread_title:  Intelligibility 

message: End of line is significantly referenced in Tron and less so in Battlestar Galactica.  Probably elsewhere.  Is it worth a brief section?  Titaniumlegs (talk) 21:42, 22 January 2020 (UTC)
thread_title:  In popular culture? 

message: There should be a section on visual representations of line breaks, such as these:
/ ⪪ ≡ ↵ ⏎ ␤ ␍ ␊
I know some of these are briefly mentioned, but there should be a section with examples of how these are used.  — Preceding unsigned comment added by 77.61.180.106 (talk) 10:25, 2 June 2020 (UTC)
thread_title:  Visual representations 

message: My contribution of the RS escape code (revision 962480569) was undone for "contradicting" this document: https://www.qnx.com/developers/docs/6.3.0SP3/dinkum_en/cpp/charset.html#Escape%20Sequences
I do not see how this contradicts that document. While C does not have a mnemonic escape sequence for the record separator character, a numeric sequence can be used (see the "Numeric Escape Sequences" section of the aforementioned document). The RS character is 30 in decimal (as documented within the article) which is 36 in octal, hence the  escape code. 68.117.55.155 (talk) 00:45, 15 June 2020 (UTC)
replies: text: The actual language was "This appears to contradict [ https://www.qnx.com/developers/docs/6.3.0SP3/dinkum_en/cpp/charset.html#Escape%20Sequences ]. Please discuss on talk page." I have restored your version. --Guy Macon (talk) 01:03, 15 June 2020 (UTC)
thread_title:  Escape codes 

message: Hello User:Guy Harris,
I can't say I understand your reasoning for changing back the capitalisation. MOS:CONFORM states:
What is the importance of leaving those words capitalised? You say "the capitalisation gives the words their magic powers" (not a direct quote). I'm not sure what that means, or why it's important in this article. Please can you elaborate? Regards, DesertPipeline (talk) 08:43, 3 March 2021 (UTC)
replies: text: RFC documents form the standards for a lot of networking and related protocols (the text in question concerns newlines in emails). If an RFC says "must" it is a sort-of opinion, but if it says "MUST" it means that the associated text is part of the standard and must be followed by compliant systems. The edit summary mentions RFC 2119 which documents this. The caps are part of computer jargon. Johnuniq (talk) 09:16, 3 March 2021 (UTC)
replies: text: Very well then. Thank you for the explanation, User:Johnuniq. DesertPipeline (talk) 09:25, 3 March 2021 (UTC)
thread_title:  IETF quote 

message: A discussion is taking place to address the redirect :Line feed. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 July 28#Line feed until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:30, 28 July 2021 (UTC)
thread_title:  "Line feed" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: The last sentence of the lead paragraph of the article  () felt very misleading to me, so I changed it. My gripe was that the wording of "some text editors" implies that this behavior is only relatively common, rather than virtually universal. Now, I know that there are, of course, situations where pressing enter doesn't produce a newline (of any type, be it  or  or  or whatever else), like in a single-line form element on a webpage it'll submit the form, and in an instant messenger it'll send a message, but still I maintain this sentence is misleading, implying that producing newlines isn't the key's primary purpose. In typical text-editing situations, whether in a text editor or a multi-line form element, Enter is the key that produces newlines, and it's a special case where it doesn't . I changed it to 
 — oatco (talk) 00:14, 29 January 2022 (UTC)
replies: text: The stuff about the Enter key should be removed as misleading and unhelpful. It's a very simplistic interpretation of what text editors typically do. Also, per WP:LEAD, the introduction should be a summary of what is in the article and I don't see an explanation regarding Enter (or a reference). There is no mention of "newline" at Enter key (it does mention producing a "new line" which is more accurate). Johnuniq (talk) 01:02, 29 January 2022 (UTC)
replies: text: Good points. I removed the sentence entirely. oatco (talk) 18:14, 29 January 2022 (UTC)
replies: text: I went ahead and also removed the second paragraph, which was just the sentence , because it was just a rewording of the first sentence. Like the old version of the now-gone Enter key sentence, it was also specific to text editors. oatco (talk) 18:25, 29 January 2022 (UTC)
thread_title:  "Some text editors" 

message: Some older teletypewriters did require CR+CR+LF, i.e. a doubling of the CR code, to give the mechanics enough time to finish their movements. Though it might be that these are (or were) all pre-ASCII, 5-bit Baudot code machines.
I saw this requirement in action on machines used by the German military in 1993/94, though the machines themselves were far older. Some of the slightly newer machines had a special key to produce CR+CR+LF, if I remember correctly that key had three horizontal lines on it, just like the modern "hamburger" symbol used to bring up a menu on web pages and other current UIs. Should this be mentioned? -- 2003:C0:972B:6C00:1A07:7E20:B066:1ECB (talk) 22:30, 22 May 2023 (UTC)
replies: text: The need for padding characters is pretty well documented, I thought there was something about it here already. Do you know if the extra characters had to be CR or would NUL work? Spitzak (talk) 23:56, 22 May 2023 (UTC)
replies: text: I don't remember CR+CR+LF being used -- but NUL certainly was (on Teletypes, but also after some control sequences on display terminals). See the new article output padding. --Macrakis (talk) 17:44, 15 January 2024 (UTC)
thread_title:  Teletypes requiring CR+CR+LF