This question already has answers here:
Difference between \n and \r?
(11 answers)
Closed 6 years ago.
I am new to Sublime Text and I saw there's a setting of Line Endings which allows me to change it to 'windows','UNIX' and 'mac os'. Can someone explain to me?
Thx~
Before there was computers, people wrote text on a typewriters.
To get to a new line on your paper, you need to feed a line (scroll the paper one line up) and do a carriage return (put the pointer on the beginning of the line).
New technologies adapted these techniques. On UNIX-like systems, native editors will not set a carriage-return (CR) flag, but only a line-feed (LF). In Windows, line endings are denoted with both CR and LF. The Mac OS setting refers to the classic Mac OS (pre-OS X), which used only CR. Modern Mac OS (OS X and macOS) uses LF, as it is UNIX-based. The Wikipedia article on Newline has a good overview.
If you are working with Windows only, leave it as it is. If you need to swap files between UNIX-like and Windows systems, set the editor on Windows to use UTF-8 encoding for files and line_ending to LF only. That way you will circumvent many problems with encoding on linux/mac machines.
Related
Good morning!
Recently I installed gvim on windows 10 and started vimtutor. My home language is Russian and vimtutor was translated by default.
After entering lesson 2.1 I found out that I can't use dw to delete words. Using this command I can delete 1 or sometimes 2 letters in a word. I can't delete the whole word as vimtutor says. Example of text from vimtutor:
Несколько слов рафинад в этом предложении автокран излишни.
For testing purposes I inserted some text using latin symbols and tested dw. Everything deletes correctly.
So when I use gvim in windows 10 I can't complete vimtutor because it works incorrect with non-latin characters. I found a similar question here Similar question The answer was "don't use cyrillic characters". Unfortunately, the answering person didn't fully understood the problem. The question was about editing non-latin text and the answer was about using non-latin symbols in command mode (which is not a problem for me).
I continued my research and found out that console version of vim in windows 10 has the same problem: I can't edit texts with cyrillic symbols.
Then I loaded my OpenSUSE i3 system and launched vimtutor there. Suddenly, all commands work correctly and I can complete vimtutor (even if it mostly contains cyrillic characters).
Do I miss some setup steps in Windows or is it a bug? Why dw don't work only on non-latin words and only in Windows?
After creating issue on Github (https://github.com/vim/vim/issues/8588) I got a respond from habamax about the problem. It seems that in old versions of Windows vim utf-8 is not used by default. Editing vimrc or using nightly build (as habamax suggested in the issue) solves the problem.
open OUT, ">output.txt";
print OUT "Hello\nWorld";
When I run the above perl code in a Unix system and then transfer output.txt to Windows and open it in Notepad it shows as:
HelloWorld
What do I need to do to get the newlines displaying properly in Windows?
Text file line endings are platform-specific. If you're creating a file intended for the Windows platform then you should use
open OUT, '>:crlf', 'output.txt' or die $!;
Then you can just
print OUT "Hello\nworld!\n";
as normal
The :crlf PerlIO layer is the default for Perl executables built for Windows, so you don't need to add it to code that will create files for its intended platform. For portable software you can check the host system by examining the built-in variable $^O
Windows uses carriage-return + linefeed:
print OUT "Hello\r\nWorld";
I wrote the File::Edit::Portable module that eliminates these problems. Although you can use it to write (along with many other things), you only need the read() functionality in this case.
Install the module, and at the top of your script, add:
use File::Edit::Portable;
When opening/reading the file, you can just do:
my $rw = File::Edit::Portable->new;
my $fh = $rw->read('file.txt');
No matter what the line endings are or what platform you're on, it does all of the cross-platform work in the background so you don't have to. That way, you can open the file on any system, regardless of what line endings you've decided to use, and it just works.
Newline handling is editor specific (there are a number of answers that claim it is OS specific, but that is, in real life, not true in general). However, it is true that on DOSish systems, longstanding convention is to use CRLF to indicate EOL (see also Why is fwrite writing more than I tell it to?)
If you try to open this file in any other editor than Notepad, you will notice that the text is properly displayed on two lines, with an indicator in a status bar or some other place that the file is opened in Unix mode or LF mode.
Unless you intend your file solely for viewing with Notepad, you don't have anything to worry about. Every other tool on Windows will deal fine with it.
However, Notepad does expect a CRLF sequence to mark the end of each line. If you do want to cater for it, then you can just output "\r\n" as #kizeloo suggests. I do prefer to use output layers when they are necessary.
Note that if you try to view such a file using an editor that requires a single LF to signify EOL, you may see ^Ms or other characters denoting the CR.
I am very new to Emacs, using Aquamacs on a Mac running OS 10.10. I'm creating and editing files that end up on a BSD system, so they need to conform to *nix standards. Apparently, the files I'm creating have carriage return line feeds, which my supervisor is understandably getting annoyed with having to strip out. I don't understand why this is the case, because my understanding is that the Mac hasn't used CR line breaks since they moved to OS 10. How can I fix this? Obviously, I'm not looking for a solution that has to be implemented for each new buffer I open, but rather a solution that will be the default for all new buffers.
While I use an editplus on windows 7 and a smultron on OSX, very annoying things happen all the time. I mean, it is okay on OSX, but when I use the same file on windows 7, the line is different and everything is messed up. I do not know what happened.
Is there any good programming editor on both operating system without any misalignment things?
Thanks.
Unix/Windows use different character sequences for determining line breaks. To fix your issue, you need to set both editors to use the same sequence, for example in smultron you can change "Line Endings" parameter to 'Dark Side (CRLF)'.
I have a PHP program that uploads a CSV file and reads through it.
We only have PC's in the office, but sometimes our clients have Macs. Is there a way to create a Mac CSV in Windows for testing purposes?
Since CSV is a text-based format, the only difference between a Mac and a PC CSV file would be the line endings. Windows typically use CR+LF for line endings, whereas Mac OS X and *nix typically use just LF.
It really depends on the software that will be reading the CSV file. There is a good chance that a well-designed reader (on either Mac or PC) would gracefully / automatically handle either LF or CR+LF endings. However, there is (naturally) no shortage of not-so-well-written software out there. Do you have more info on what software they will be using?
If you want to explicitly create a CSV file in "Mac-friendly" mode, you could open the file in binary mode, and explicitly use "\n" (rather than "\r\n") at the end of each line. This will likely open / view fine on most apps within windows. (Though Notepad won't like it, Excel probably will.) This file should then be "optimized" for Mac output. Though, as above, it might not matter at all, if the client's software is "tolerant" of different endings.
EDIT: Prior to OS X, Mac used CR (\r) for line endings. For OS X, they switched to LF (\n). Most likely, your clients are using OS X, so \n is likely the ending you want.
There's no such thing as a 'Mac CSV'. A CSV is a document with values that are comma-separated (that's why they call it a "Coma-Separated Values file). In other words, it's plain text.
The only edge cases I could see are line endings (which is likely to be \n but could also be \r) and encoding (which is very likely to be UTF-8 but could somehow be Mac Roman) if your clients use non-ASCII characters.