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 [TIP]s, 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 ... <<br>>`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 ''fd''s 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 [http://www.tcl.tk/cgi-bin/tct/tip/304.html] 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:

    * [tclx signal commands for core]
    * [tclx system control commands for core]



<<categories>> Suggestions | Tclx