Re: Double Spacing in Mails from Sendmail
This WebDNA talk-list message is from 2002
It keeps the original formatting.
numero = 42868
interpreted = N
texte = > By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... Of course, John. I just though it would be nice to explain what was going on. That code hasn't changed in years, so it must have been an issue for quite some time.> OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. Again, I was just explaing what was going on. I certainly was not proposing that the code is correct as is. >I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. Straight from the MS docs...(regarding a file that is opened in text mode)... Also, in text mode, carriage return-linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return-linefeed combinations on output. I've confirmed this to be true, If my test email body contains a
sequence, after the fwrite() call, the email text file contains a sequence. > I'll bet dollars to donuts you have a \r in the fprint(). Nope. The message body is written out using fwrite(), no '\r' characters involved. But because the file was opened in text mode, characters are converted as I explained previously. I think this was just an oversight when the WebDNA engine was ported to the Windows platform. Sorry it took so long to get to the bottom of this issue. > -----Original Message----- > From: WebCatalog Talk > [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > Of John Peacock > Sent: Friday, August 23, 2002 3:55 AM > To: WebCatalog Talk > Subject: Re: Double Spacing in Mails from Sendmail > > > Scott Anderson wrote: > > Looks like a [sendmail] bug (but only on the Windows platform) > > By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... > > > > > The [sendmail] context opens the email file in 'text' mode, > so there is a > > translation taking place where linefeed characters are > replaced with > > carriage-return linefeed pairs . The header lines > work fine because > > [sendmail] explicitly inserts only a at the end of > each header (which > > is then translated to pair by the fprintf() call). > But the body is > > written out as is. So if the body contains a > sequence, this > > becomes a sequence during the fwrite() call. > > OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. > I realize that WebCat started as a Mac-only package, but come > on, that was 7 > years ago! Out of the box, with no mucking about by anyone, > Windows EOL > characters will produce RFC compliant e-mails. > > The RFC's require CR/LF in the header and do not require any > special EOL > handling in the body. All compliant MTA's I am aware of will > take CR or LF or > CR/LF as an EOL character when found in the body. Any > special handling you > perform should only be directed at the header lines. > > Here's what you should be doing, and it will work for all > platforms out of the box: > > 1) For header lines only, strip whatever EOL character(s) you > find and always > output CR/LF pairs; > > 2) Do not perform any EOL modifications to body text. > > > > > A work around would be to make sure the text within your > [sendmail] contexts > > tags contain UNIX style line endings. > > > > I'll test this, but I believe that we tested this ages ago > and it did not fix > it. I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. On output, text mode under Windows will always give you > CR/LF, so if you > are doing anything different in the fprint(), you are causing > the problem > yourself. I'll bet dollars to donuts you have a \r in the fprint(). > > John > > -- > John Peacock > Director of Information Research and Technology > Rowman & Littlefield Publishing Group > 4720 Boston Way > Lanham, MD 20706 > 301-459-3366 x.5010 > fax 301-429-5747 > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
> By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... Of course, John. I just though it would be nice to explain what was going on. That code hasn't changed in years, so it must have been an issue for quite some time.> OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. Again, I was just explaing what was going on. I certainly was not proposing that the code is correct as is. >I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. Straight from the MS docs...(regarding a file that is opened in text mode)... Also, in text mode, carriage return-linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return-linefeed combinations on output. I've confirmed this to be true, If my test email body contains a sequence, after the fwrite() call, the email text file contains a sequence. > I'll bet dollars to donuts you have a \r in the fprint(). Nope. The message body is written out using fwrite(), no '\r' characters involved. But because the file was opened in text mode, characters are converted as I explained previously. I think this was just an oversight when the WebDNA engine was ported to the Windows platform. Sorry it took so long to get to the bottom of this issue. > -----Original Message----- > From: WebCatalog Talk > [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf > Of John Peacock > Sent: Friday, August 23, 2002 3:55 AM > To: WebCatalog Talk > Subject: Re: Double Spacing in Mails from Sendmail > > > Scott Anderson wrote: > > Looks like a [sendmail] bug (but only on the Windows platform) > > By which you mean you are going to fix it? Soon? I've been > complaining about > this for literally years. And it didn't always misbehave like this... > > > > > The [sendmail] context opens the email file in 'text' mode, > so there is a > > translation taking place where linefeed characters are > replaced with > > carriage-return linefeed pairs . The header lines > work fine because > > [sendmail] explicitly inserts only a at the end of > each header (which > > is then translated to pair by the fprintf() call). > But the body is > > written out as is. So if the body contains a > sequence, this > > becomes a sequence during the fwrite() call. > > OK, that't just plain wrong! Your code (i.e. WebCat) has no > business messing > with the EOL characters, ever, on platforms that do not need > it, like Windows. > I realize that WebCat started as a Mac-only package, but come > on, that was 7 > years ago! Out of the box, with no mucking about by anyone, > Windows EOL > characters will produce RFC compliant e-mails. > > The RFC's require CR/LF in the header and do not require any > special EOL > handling in the body. All compliant MTA's I am aware of will > take CR or LF or > CR/LF as an EOL character when found in the body. Any > special handling you > perform should only be directed at the header lines. > > Here's what you should be doing, and it will work for all > platforms out of the box: > > 1) For header lines only, strip whatever EOL character(s) you > find and always > output CR/LF pairs; > > 2) Do not perform any EOL modifications to body text. > > > > > A work around would be to make sure the text within your > [sendmail] contexts > > tags contain UNIX style line endings. > > > > I'll test this, but I believe that we tested this ages ago > and it did not fix > it. I believe you are not understanding text mode correctly > under Win*, since > that is supposed to treat CR/LF as \n and automatically > upgrade CR => \n for > you. On output, text mode under Windows will always give you > CR/LF, so if you > are doing anything different in the fprint(), you are causing > the problem > yourself. I'll bet dollars to donuts you have a \r in the fprint(). > > John > > -- > John Peacock > Director of Information Research and Technology > Rowman & Littlefield Publishing Group > 4720 Boston Way > Lanham, MD 20706 > 301-459-3366 x.5010 > fax 301-429-5747 > > > ------------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > > Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Scott Anderson
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Introduction/Tutorial/QuickStart (1997)
Interfacing WebMerchant to www.fedex.com (1997)
Database wiped clean (2005)
Globals folders (2004)
NT version and O'reily's WebSite (1997)
Separate SSL Server (1997)
Server crash (1997)
Just Testing (1997)
Ampersands in database fields? (1998)
[WebDNA] Determining when a TCPConnect timeout occurs (2010)
Euro WebDNA Conference (2004)
creating writefile data from a nested search (1997)
A question on sub-categories (1997)
Date search bug (1997)
Fwd: 502 Bad Gateway (1998)
Quit revisited (1997)
problems with 2 tags (1997)
Problem displaying search result (1997)
autosensing lanague selection (1997)
WebCat2b15MacPlugin - showing [math] (1997)