fileshistorynewlines
As far as I know, every operating system has a different way to mark the end of line (EOL) character. Commercial operating systems use carriage return for EOL (carriage return and line feed on Windows, carriage return only on Mac). Linux, on the other hand, just uses line feed for EOL.
Why doesn't Linux use carriage return for EOL (and solely line feed instead)?
(As this does not answer the question, this is should have been a comment, but is too long - so treat it as a comment).
As an alternative to FreeBSD's xargs you can use GNU Parallel which does not have this limitation. It even supports repeating the context:
seq 10 | parallel -Xj1 echo con{}text
seq 10 | parallel -mj1 echo con{}text
GNU Parallel is a general parallelizer and makes is easy to run jobs in parallel on the same machine or on multiple machines you have ssh access to. It can often replace a for loop.
If you have 32 different jobs you want to run on 4 CPUs, a straight forward way to parallelize is to run 8 jobs on each CPU:
GNU Parallel instead spawns a new process when one finishes - keeping the CPUs active and thus saving time:
Installation
If GNU Parallel is not packaged for your distribution, you can do a personal installation, which does not require root access. It can be done in 10 seconds by doing this:
(wget -O - pi.dk/3 || curl pi.dk/3/ || fetch -o - http://pi.dk/3) | bash
For other installation options see http://git.savannah.gnu.org/cgit/parallel.git/tree/README
Learn more
See more examples: http://www.gnu.org/software/parallel/man.html
Watch the intro videos: https://www.youtube.com/playlist?list=PL284C9FF2488BC6D1
Walk through the tutorial: http://www.gnu.org/software/parallel/parallel_tutorial.html
Sign up for the email list to get support: https://lists.gnu.org/mailman/listinfo/parallel
Took me long enough but here I am at last! I've had to download minicom source code to get an idea what to do to avoid the hassle of constantly pressing Ctrl+Z, U... Here it is.
minicom stores its parameters in a configuration file, which defaults to $HOME/.minirc.dfl. Put the following line, to the letter:
pu addcarreturn Yes
and now minicom adds a carriage return to all incoming lines. I have no idea why it didn't save that option along with its configuration file in the first place but, heck, I don't care now!
Beware that every option after pu must take exactly 16 characters, padded with spaces to the right.
Best Answer
Windows uses CRLF because it inherited it from MS-DOS.
MS-DOS uses CRLF because it was inspired by CP/M which was already using CRLF.
CP/M and many operating systems from the eighties and earlier used CRLF because it was the way to end a line printed on a teletype (return to the beginning of the line and jump to the next line, just like regular typewriters). This simplified printing a file because there was less or no pre-processing required. There was also mechanical requirements that prevented a single character to be usable. Some time might be required to allow the carriage to return and the platen to rotate.
Gnu/Linux uses LF because it is a Unix clone.1
Unix used a single character, LF, from the beginning to save space and standardize to a canonical end-of-line, using two characters was inefficient and ambiguous. This choice was inherited from Multics which used it as early as 1964. Memory, storage, CPU power and bandwidth were very sparse so saving one byte per line was worth doing. When a file was printed, the driver was converting the line feed (new-line) to the control characters required by the target device.
LF was preferred to CR because the latter still had a specific usage. By repositioning the printed character to the beginning of the same line, it allowed to overstrike already typed characters.
Apple initially decided to also use a single character but for some reason picked the other one: CR. When it switched to a BSD interface, it moved to LF.
These choices have nothing to do with the fact an OS is commercial or not.
1 This is the answer to your question.