ables@catwoman.ACA.MCC.COM (King Ables) (08/10/88)
We noticed a strange timing problem in /usr/ucb/Mail today
that we've been seeing for some time (so I suspect it exists
in MANY versions). We are currently running SunOS 3.5 on
the machine where the problem occurs, but have observed *at
least* as far back as 3.0. I suspect it exists from the original
Berkeley code.
The problem occurs when replying to a message which many
recipients and you ^D at the end of the message and the CC:
line is shown to you (you have askcc set in your .mailrc).
If the Cc: line has several addresses on it so that it wraps
to a 2nd line AND if you hit ^D and <RETURN> (the <return> in
response to the Cc: line prompt) VERY QUICKLY, there seems
to be a timing problem where the 2nd line's worth of text (the
part that was wrapped) isn't gathered up and processed so you
wind up with a partial CC: line going out. This has the effect
of possibly leaving some people off the Cc: line and usually
cutting some address in half so that it no longer is a valid
address (half a hostname or some such).
Has anyone noticed this before and has anyone ever done anything
about it? I don't want to go figuring it out for myself is someone
already has fixed it.
Thanks for any info.
-king
ARPA: ables@mcc.com
UUCP: {gatech,nbires,seismo,ucb-vax}!cs.utexas.edu!pp!ablesdheller@cory.Berkeley.EDU (Dan Heller) (08/10/88)
> ables@catwoman.ACA.MCC.COM (King Ables) writes: >We noticed a strange timing problem in /usr/ucb/Mail today... >The problem occurs when replying to a message which many >recipients and you ^D at the end of the message and the CC: >line is shown to you (you have askcc set in your .mailrc). >If the Cc: line has several addresses on it so that it wraps >to a 2nd line AND if you hit ^D and <RETURN> (the <return> in >response to the Cc: line prompt) VERY QUICKLY, there seems The problem is the ucbMail uses TIOCSTI to retype your Cc: line as if you typed it. This is how Mail gives you your headers and positions the cursor in the right place without having to put you in cbreak/noecho mode to keep track of how many chars to allow you to backspace. The timing problem is a correct assumption ... apparently, the BSD driver allows certain characters to sneak in before normal chars. So, when you hit CR or ^D, that gets interpreted immediately and the rest of the string is either lost or sent to whatever wants to read your input next. Those of you who use command line completion in csh on sunOS or similar shells might notice the same problem (that you *must* wait for the completion or the whole line is fubar). There is no fix for this -- just wait till the whole line prints before you hit your CR or ^D or use a better mail interface than Mail. Dan Heller <island!argv@sun.com>
chris@mimsy.UUCP (Chris Torek) (08/10/88)
In article <13@catwoman.ACA.MCC.COM> ables@catwoman.ACA.MCC.COM (King Ables) writes: >We noticed a strange timing problem in /usr/ucb/Mail ... >I suspect it exists from the original Berkeley code. >The problem occurs [anytime you are editing a header, actually]. >... If the Cc: line has several addresses on it so that it wraps >to a 2nd line AND if you hit ^D and <RETURN> (the <return> in >response to the Cc: line prompt) VERY QUICKLY, there seems >to be a timing problem where the 2nd line's worth of text (the >part that was wrapped) isn't gathered up and processed so you >wind up with a partial CC: line going out. This description is flawed, but the effect is right: if you hit return fast enough, part of the text intended for that line appears on the next line (possibly the command). The same thing happens when using ~h, although for whatever reasons, people tend to be slower to bang on the return key here. The bug has existed ever since the TIOCSTI ioctl was added, and is very simple and very hard to fix. The Mail program uses TIOCSTI (`Tty IO Control, Simulate Terminal Input') to stuff characters into the tty input queue, as if you had typed them yourself. You can then edit them using the kernel tty input code. This is a nice way to implement single-line editing, but it has a serious flaw: TIOCSTI does exactly what it implies. The TIOCSTI ioctl passes a character to the tty input code, where it is treated just as if you typed it just then. Hence if you type *before* Mail gets around to doing a TIOCSTI, what you typed goes in front of what Mail `types'. Moreover, if for some crazy reason you like to use the letter `w' as your line kill character, when Mail tries to push back the Cc line aglew@gould.com you wind up with the string @gould.com since the `w' did a line kill. The best fix for the problem is to replace TIOCSTI with something useful. At least two operations are needed, one to push a string in front of the tty queue, and one to push it after; it would also help if one could automatically quote any special characters. Alternatively, one could remove tty line editing from the kernel entirely, and again replace TIOCSTI with something useful, but outside the kernel. Either way, just changing Mail will not do it. (Another possibility is to make Mail run in cbreak mode, and have it simulate the kernel's tty input editor. There is or was code in Mail to do this. This solution is at least as unsatisfactory as TIOCSTI.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
sahayman@watmath.waterloo.edu (Steve Hayman) (08/11/88)
Chris Torek discusses problems with Mail's "~h" and TIOCSTI and suggests >Either way, just changing Mail will not do it. > >(Another possibility is to make Mail run in cbreak mode, and have it >simulate the kernel's tty input editor. There is or was code in Mail >to do this. This solution is at least as unsatisfactory as TIOCSTI.) Another another possibility is to arrange that "~e" and "~v" in Mail let you edit the whole message, headers and all. We did that here (actually we added "~E" and "~V" commands, to edit the whole message as opposed to just the text), which sort of eliminates the need for this TIOCSTI stuff. (and which also lets you add neat headers like "Return-Receipt-To:".) If anyone's interested in these changes, let me know and I can try to make them into a patch. ..Steve -- Steve Hayman Math Faculty Computing Facility University of Waterloo watmath!sahayman sahayman@math.waterloo.edu sahayman@water.bitnet
john@jetson.UPMA.MD.US (John Owens) (08/12/88)
In article <13@catwoman.ACA.MCC.COM>, ables@catwoman.ACA.MCC.COM (King Ables) writes: > We noticed a strange timing problem in /usr/ucb/Mail today > ... > If the Cc: line has several addresses on it so that it wraps > to a 2nd line AND if you hit ^D and <RETURN> (the <return> in > response to the Cc: line prompt) VERY QUICKLY, there seems > to be a timing problem where the 2nd line's worth of text (the > part that was wrapped) isn't gathered up and processed so you > wind up with a partial CC: line going out. Yep. This is a consequence of the way Mail is allowing you to edit that input line. This will also happen if you use ~h to edit the headers. What it does is to print a prompt, "Cc: ", then it does a sequence of TIOCSTI ioctl's to Simulate Type-In of the characters in the current Cc: line. This subjects the current characters to the tty driver editing features, allowing you to kill the line, backspace, ^W, etc. However, if you input a character while it's simulating type-in of the other characters, your character will be interspersed. I don't know of any way around this, without rewriting mail to not use TIOCSTI and cooked mode at all (and use it's own cbreak-mode line editor). Just wait for the Cc: lines (and the ~h output). -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)