We have a Centos 5.8 32 bit server that has been printing fine since we installed it. Recently, we also installed a new server with 64 bit Centos 6.4. On both servers, we print all reports with a simple 'lp' command. The new server prints all reports with double spacing. We looked at the text file that is being printed and found that it contains both '<cr>' and '<nl>' characters. On the 5.8 server, this does not seem to be a problem, but on the 6.4 server, it is. Does anyone know of a fix for this problem?
Thanks BDavis
On 26.Aug.2013, at 00:25, Billy Davis wrote:
We have a Centos 5.8 32 bit server that has been printing fine since we installed it. Recently, we also installed a new server with 64 bit Centos 6.4. On both servers, we print all reports with a simple 'lp' command. The new server prints all reports with double spacing. We looked at the text file that is being printed and found that it contains both '<cr>' and '<nl>' characters. On the 5.8 server, this does not seem to be a problem, but on the 6.4 server, it is. Does anyone know of a fix for this problem?
rfc 2822 says
- CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.
so in mail, a new line is \r\n In a unix environment, if you write text, a new line is only \n something has to convert \n to \r\n for mail
But what to do if there is already \r\n ? sendmail accepts it as it is, it seems, \r\n is passed through postfix acts slightly different, it knows that the new line separator is \n and this \n is converted to \r\n, but the first \r remains, and rfc 2822 says , hey above quote, MUST NOT appear independently, so it makes the \r to \r\n, the end result is \r\n\r\n
On UNIX the newline character is only \n per definition, and if you feed text to a unix binary that is supposed to convert the text to something rfc compliant, then your best strategy is probably to feed the text according to unix newline rules. On unix do not end text with \r\n.