Tcl Source Code

OriginalBugID: 6294 Bug
Version: 8.3
SubmitDate: '2000-09-21'
LastModified: '2000-10-25'
Severity: MED
Status: UnAssn
Submitter: techsupp
OS: Windows 95
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name:
Schrödter

Comments:
Please check the man-syntax of the patch, because I do not have a 
    completely featured man-formatter on my Win95 system.

ReproducibleScript:
set chan [open com1: r+]
fconfigure $chan -mode 19200,n,8,1 -buffering none -blocking 1
read $chan     ;# blocks forever, because there is no end-of-file

ObservedBehavior:
This behaviour has been discussed in comp.lang.tcl with Jeffrey Hobbs.
The conclusion was that the documentation on reading serial ports 
should be improved.

Patch:
*** read.nTue May 04 18:19:42 1999
--- read.n.newThu Sep 21 09:48:58 2000
***************
*** 51,56 ****
--- 51,74 ----
  See the \fBfconfigure\fR manual entry for a discussion on ways in
  which \fBfconfigure\fR will alter input.

+ .SH "SERIAL COMMUNICATIONS"
+ For most applications a serial port should be configured as nonblocking:
+ \fBfconfigure \fIchannelId \fB\-blocking \fI0\fR. Then \fBread\fR behaves
+ much like described above.
+ .PP
+ Care must be taken when using \fBread\fR on blocking serial ports:
+ .TP
+ \fBread \fIchannelId numChars\fR
+ .
+ In this form \fBread\fR blocks until \fInumChars\fR are received from the 
+ serial port.
+ .TP
+ \fBread \fIchannelId\fR
+ .
+ In this form \fBread\fR blocks until the reception of the end-of-file 
+ character, see \fBfconfigure -eofchar\fR. If there is no end-of-file character 
+ specified, then \fBread\fR may block forever.
+ 
  .SH "SEE ALSO"
  eof(n), fblocked(n), fconfigure(n)

PatchFiles:
read.n

File Added - 4560: read.patch

Logged In: YES 
user_id=79902

Gone through the wording for increased clarity, and
converted to a UniDiff.  Applies against version 1.5 of
doc/read.n

(Must convert to a patch, and check to see whether it applies cleanly to the current doc tree - this change looks good in principle to me.)