Purpose: To get [TclX] file functionality into the core.  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 ... [[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 :)

----
See Also:

    * [tclx signal commands for core]
    * [tclx system control commands for core]
----
[Category Suggestion]