TCL end of line character

This topic has 8 replies, 4 voices, and was last updated 16 years, 9 months ago by Steve Carter.

Creator

Topic
January 8, 2007 at 6:35 pm #48985
Kevin Scantlan
Participant
I’m noticing a difference between how TCL handles the “gets” command between 2 environments. We recently upgraded our test machine to CLoverleaf 5.4.1 and a new TCL although I’m not certain the version. Our production machine is still at Cloverleaf 5.2.1 . I took a file containing an HL7 message and placed it in both machines. I went into the TCL enviroment by entering “tcl” from the command prompt. I then entered the following:

set fileid [open filename.dat r]

set line [gets $fileid]

On the test machine, the variable “line” only contained the first segment of the message while on the production machine “line” contained the entire message.

The only difference that I can think is how the command interprets the “end of line” character or what it thinks it is.

Any suggestions?
Creator

Topic

Viewing 7 reply threads

Author

Replies
- January 8, 2007 at 8:45 pm #60325
  Glenn Friedenreich
  Participant
  Hi Kevin – Charlie Bursell mentioned this difference in TCL 8.4 at this past year’s User Conference. Apparently TCL 8.4 (which is what Cloverleaf 5.4.1 uses) tries to “help” you by converting carriage-returns to carriage-return/new lines, like Windows does. Of course, this isn’t much of a help in an HL7-formatted file.
  
  The fconfigure command should fix it:
  
  set fileid [open filename.dat r]
  
  fconfigure $fileid -translation lf
  
  set line [gets $fileid]
  
  – Glenn
- January 8, 2007 at 8:51 pm #60326
  Kevin Scantlan
  Participant
  And we need to place this in EVERY script that we have that does this? Or is there someplace we can “define” the end-of-line character for the machine?
- January 8, 2007 at 9:55 pm #60327
  Steve Carter
  Participant
  You can place the following lines of code into $HCIROOT/tcl/lib/localInit.tcl
  
  ***********************************
  
  rename open fileOpen
  
  proc open { fileName { access “r” } { permissions “0666” } } {
  
  set fileHandle [ fileOpen $fileName $access $permissions ]
  
  fconfigure $fileHandle -encoding binary -translation binary -eofchar {}
  
  return $fileHandle
  
  }
  
  ***********************************
  
  In effect, this rewrites the open command and allows you to configure the channel to keep the EOL characters intact. This is a global change. Which is exactly what I needed. Going through our entire system and adding an fconfigure to every open was not an option.
  
  One other thing, if you use the read_file command, you’ll need the following code added right below the code above:
  
  ************************************
  
  rename read_file {}
  
  proc read_file { args } {
  
  if {[string equal [lindex $args 0] -nonewline]} {
  
  lvarpop args
  
  set nonewline 1
  
  } else {
  
  set nonewline 0
  
  }
  
  set fileName [ lvarpop args ]
  
  set numBytes [ lvarpop args ]
  
  set fd [ open $fileName r ]
  
  fconfigure $fd -translation binary
  
  if {$nonewline} {
  
  set str [read -nonewline $fd]
  
  } else {
  
  if { $numBytes != “” } {
  
  set str [read $fd $numBytes]
  
  } else {
  
  set str [read $fd]
  
  }
  
  }
  
  close $fd
  
  return $str
  
  }
  
  I ran into the same problem. I’m sure Charlie will let you know if I’ve missed something here.
  
  Steve
- January 9, 2007 at 2:00 pm #60328
  Kevin Scantlan
  Participant
  It might be nice to be able to rewrite the gets command to be something like this:
  
  gets: proc { parm1, parm2 } {
  
  set fileid [gets parm1 parm2]; access the original gets
  
  fconfig $fileid -translate lf
  
  }
  
  the key here is that the gets within the proc doesn’t access itself but accesses the original “gets”. But I don’t know where the original “gets” is located.
- January 9, 2007 at 3:09 pm #60329
  Steve Carter
  Participant
  It doesn’t actually matter where the original ‘gets’ is located.
- April 25, 2007 at 5:47 pm #60330
  Steve Carter
  Participant
  BTW….this little ‘feature’ is fixed in 5.5.
  
  The init.tcl now contains ‘set EuroBinary 1’.
- March 11, 2008 at 6:50 pm #60331
  ian.smith
  Participant
  ~~Steve Carter wrote:~~
  
  BTW….this little ‘feature’ is fixed in 5.5.
  
  The init.tcl now contains ‘set EuroBinary 1’.
  
  How does EuroBinary affect the End Of Line Character?
- March 11, 2008 at 7:54 pm #60332
  Steve Carter
  Participant
  By toggling EuroBinary off or on (0 or 1), it controls how the EOL characters are interpreted during a read from a file handle. A value of ‘0’ causes the EOL characters to be translated to the local system’s preferred EOL characters. A value of ‘1’ leaves the EOL characters intact during the read. Basically, it’s the same difference you’d see during an ASCII or BINARY ftp session.
  
  Steve
Author

Replies

Viewing 7 reply threads

The forum ‘Tcl Library’ is closed to new topics and replies.