Why was this thing called 'chan' instead of 'channel'? schlenk: It's mentioned in the TIP [2], basically the same naming style as interp for interpreter.

I see. Thank you for pointing that out. Pretty lame reasoning when "channel" is much more descriptive. But I'm not the one doing all the work so I'm not complaining!

JYL If you dont like chan you can do 'interp alias {} channel {} chan'

---

TIP 287 proposes a [chan available channelId] command to find out how much available input is currently being buffered that could be chan read in. (It would make it safe to use chan gets with sockets since you could introspect and detect someone sending an excessively long line rather than running out of memory first.)

See also chan mode for an example how to extend that ensemble.

---

RS History sometimes runs in circles... Tcl 2.1 didn't have commands dealing with channels. Peter da Silva added the "stream" extension, where one could write

  stream fp open $filename r
  set x [stream fp gets]
  stream fp close

Later, the parts of "stream" went into the core as separate commands. Still later (in 8.5), they get reunited again in chan, which arguably makes the command set leaner, but scripts wordier...

---

MG has just needed to find out how long the eol sequence in a particular file was. Checking fconfigure $fid -translation didn't help (as it was just 'auto' on the read, and always crlf (Win XP) on the write, even if the file used Unix line-endings). Came up with this (which is possibly obvious, but I'm rather pleased with myself anyway;)

proc lineEndingSize {file} {
    set fid [open $file r]
    chan gets $fid line
    set size [expr { [chan tell $fid] - [string bytelength $line] }]
    close $fid
    return $size;
}

DKF: That can go wrong. The problem is that you need to use the encoded length of the string read, and some encodings have multiple ways of encoding a particular character. This is all rather nasty; even guessing based on the value of fconfigure -encoding can go wrong! So instead try this:

proc lineEndingSize file {
   set f [open $file]
   gets $f line
   set after [tell $f]
   seek $f 0
   read $f [string length $line]
   set before [tell $f]
   close $f
   return [expr {$after - $before}]
}

MG I'll try that instead, thanks :)

---

CliC I'm just starting out with Tcl, and happened to come across this while looking up some info on fconfigure and fileevent. The TIP mentions chan as sort of an aggregation of the file/channel-related commands, to make things easier and more consistent for new users (like me).

It also mentions a recommendation to deprecate some of the old commands, for consistency's sake. My question is, is that recommendation going to be adopted? Should I as a new user (with no legacy code or burned-in Tcl habits) do "chan <everything>" rather than fconfigure, fileevent, etc? Thanks. (Note: 2010-11-15 Updated my nick on this comment, and still curious whether file, fconfigure, and everything following the word "like" under each chan * definition above will be deprecated.)

AMG: [chan] aggregates all the commands you'll need for working with channels, except creating traditional channels (it can only create pipes and reflected channels). Use [open] or [socket] or an extension command, same as always. If you find a core channel command not incorporated as a [chan] subcommand, please report it.