Unix, RFC, Line Truncation

By Xah Lee. Date:

[Note: unix tradition requires that a return be inserted at every 78 characters in email messages. Unixers made this as a “recommendation” into RFC documents (RFC 2822).]

This truncation of lines business is a hatred of mine, from email formatting to formatting of program code. I have been fighting with the unix slew of morons about the line cut for years. The unix morons are the number one excuse expert, that whenever in a argument they'll mention some RFC “specifications”. (RFC = Really F���ing Common, invented by mostly unix folks in the 70s.)

The unix morons, think that the world should truncate lines just like their incompetent operating system silently truncate lines (and it still DOES, folks! For example: ps, tar, tcsh.) Around 1998 when i was using Mac Outlook Express or Eudora before that, i remember i can set lines to not hard-wrap, and i did. Boy that always pissed the unix blockheads. In their diddly eyes and lousy email software, i'm breaking standards, making things hard to read, and being a stupid ass. Their brain fail to see what unix ways are not capable of. These guys are the same slew of morons who cry in pain about how the web should not commercialize (circa 1996), and email should be text only (anti-MIME, circa 1995), and lynx is the best browser (circa 1995), and GUI is for sissys and mouse is for pussies and Apple computer is for kids (circa 1990).

There is no reason for a paragraph to be splattered with end of line characters, nor the human labor expended. There is reason for paragraphs to be displayed not too wide, and that is readability. What the unixer could not get clear of is a distinction of concepts. Because their fantastically hacked-up operating system operate by the principle that lines should not be longer than some 80 chars or else it will be truncated and *silently* too, thus it became NECESSARILY their HABIT and thought that line truncation business is natural and a human duty. Unknown of these setups, the unix geeks go by their presumption that all text should be hard wrapped, as if parameters should be hard-coded.

I recall, two particular unix hotshots who bugged me about the line truncations business is the Perl priest Tom Christiansen, who used to reside over comp.lang.perl.*, and another unix jockey Chris Nandor, who was a MacPerl proponent now the main maintainer. It is not a coincidence that the people who go out of their way to complain about any format=flowed or soft-wrapped or logically-formatted lines in emails are always the unixers. The unix twits will start a flame war over a petty formatting issue, because it's unix's training to bent over pettiness, not to mention they are the ones who are retarded on the issue of line truncation.

As i have alluded to above, there are serious problems with the line-truncation ways of thinking. The gist is that it is a form of physical formatting as opposed to logical. (think soft-wrap vs hard-wrap, parameter vs hard-code) Those who are familiar with the history or reason for SGML and HTML should understand the problem. Many of you familiar with drive of evolution of HTML from 1995 days to today's CSS and XML should also understand the issue. We wish to encode information, and be flexible about representation, not botching info into one particular representation.

The harm done by the unixers to society is of a long lasting and pervasive nature. First is the RFC, which serves as the mob's standard, which requires that every emailer should be broken like unix, so that unix can process them without problems. FCK unix and fck unix geeks. Secondly, it drains human labor. Right this second there are hundreds of people pressing returns or fixing jagged lines unnecessarily. Thinking and computer could have done that for us, if not for fcking stupid unix and its people. Thirdly, a generation of programs and programer's times are wasted over tools that mutilate paragraphs into pieces. (in emacs, there's fill-paragraph etc, in BBEdit it's “Hard Wrap”, In Email clients usually transparent under Preferences) Fourthly, physical formatting ultimately multiply the process required on the data, as we can see in emails, especially in combination with the stupid quote convention: “>” (that's another unix invention.). But most importantly is that the hard-liners instilled a bad notion, a confusion, that generated a entire generation of utterly stupid programing languages and monkey coders, starting with unix's C language. [see The Harm of hard-wrapping Lines]


Addendum: I got first burned seriously by the line truncation business when around 1998 i was moving my website from one server to another. Upon untarring, the file names have been changed to gibberish. The full path was about 120 characters. Apparently, the version of tar or untar i was using have problems dealing with path that's longer that 120 chars. (i don't remember if it was GNU tar/untar or BSD's version. The origin server was running Irix.)

AS LATE AS 2001, unix tool tar still truncate long path or file names.

Apple Computer Incorporated's Mac OS X, which is a new variant of unix based on BSD unix, had to replace it with GNU's Not Unix's utility. The following sites record this fact.

The line truncation in unix is not just in tar but in about every unix command line tool. It is part of the brainless coding exalted as Unix Philosophy Implementation Simplicity. This is one of the reason Perl the language was born. [see The Nature of the Unix Philosophy]

As late as 2002, Sun Microsystem's Solaris 8 is the most deployed unix in the IT industry. Its “ps” tool still truncate lines, making scripts that test running processes unreliable.

In the industry, the problems created by unix are habitually tolerated. Unixers adapt to it. For example, because unix truncate lines, thus in the unix culture, lines are always kept short, and programs, files, paths avoids long names.

If you have a question, put $5 at patreon and message me.

  1. Unixer Plain-Text Email Fetish
  2. Unixers, RFC, and Perl
  3. Unix and the mbox Email Format
  4. Unix, RFC, Line Truncation
  5. Idiocy Of Unix Copy Command
  6. The Elements Of Style: UNIX As Literature
  7. On Unix Filename Characters Problem
  8. Unix And Literary Correlation
  9. What's the Max Number of Directories a Directory Can Have?
  10. Rob Pike on the Origin of Dot File Names
  11. Unix, Security, and FTP
  12. Is Mac OS X Unix?
  13. The Unix Pestilence: MySQL
  14. Mac OS X SSH Session Disconnection
  15. Mac OS X Changes To Unix
  16. On Microsoft Hatred