Updated 2013-08-15 15:01:18 by dkf ▲

Purpose: To get TclX file functionality into the core.

LV by core, do you mean create an extension that is distributed along with the Tcl source code, just as the http extension, etc. are today or do you mean modify the Tcl generic/etc. c files so that these commands are a part of the basic Tcl language?

CMcC: I'm easy, Larry. I think they should be distributed with the core tcl, but I'm also generally in favour of modularising tcl core as much as possible (personal preference.) I guess that means shipping an extension with the source code. Or perhaps as part of a binary tcllib (as was suggested in TclX Future.)

These will eventually become TIPs, so any comments or suggestions would be welcome now. Question: is it practical to push for this stuff to be included in the 8.5 release? There is some discussion/question as to the wisdom of doing this in TclX Future.

The -keepalive option should be added to fconfigure for sockets. Possibly other sockopts should be added to fconfigure too.

Changes to tcl's file command

A new file option -fileid to allow an open file to be processed in place of the file name argument. (This may not be possible under windows.)

  1. file truncate file for tclx's ftruncate
  2. file lock file for tclx's flock
  3. file unlock file for tclx's funlock
  4. file dup fd for tclx's dup
  5. file set fd fd ... not part of tclx, but would be nice ...
    file set stderr [open /tmp/log a+]
  6. file pipe ?var_r ?var_w for tclx's pipe command.
  7. file pty ?var_r ?var_w to create a pseudo-tty with some of the facilities expect provides.
  8. file isatty fd predicate returning true if fd is a tty.

Implementation Considerations

  • The addition of -fileid semantics may be a fair bit of work
  • Interactions with things like Trf
  • Should file be made into an actual ensemble command? Perhaps we're not far enough along with that technology yet.
  • Can/Should file be moved off as a distinct module within tcl itself?
  • Are the things named by fds refcounted? They'd have to be, if [file dup] and [file set] were to be implemented. It follows, then, that since TclX has dup, they are :)

DKF: Some of these things are actually there if you know what to look for. In particular, 8.5 includes chan truncate and (since 8.4) tty-connected channels can be distinguished by the options returned when you introspect on them using fconfigure/chan configure.

EG: chan pipe is specified in TIP #304 [1] and available since 8.6b1 at least.

DKF: Going through the set to produce a smaller one:

  1. chan truncate is done.
  2. lock/unlock are tools that I'm not really all that keen on
  3. dup/set can be worked around (in particular, you can set standard channels with trickery).
  4. chan pipe is done.
  5. I'd rather leave pty handling to expect.
  6. A channel refers to a tty if (and only if) it has the serial options. Really.

This means that it's locking that remains undone (and possibly duplication). I'm also not keen on doing magic for a -fileid option; I'd rather support an fstat()-like operation through chan configure (returning a dictionary).

See Also:

Category SuggestionsCategory Tclx