[SEH] 20060110 -- An update of this code has been posted to a Sourceforge project site [http://filtr.sourceforge.net/].  All future updates will be placed there as well. 

 # fishvfs.tcl --
 #
 # A "FIles transferred over SHell" virtual filesystem
 # This is not an official "FISH" protocol client as described at:
 #      http://wiki.tcl.tk/12792
 # but it utilizes the same concept of turning any computer that offers
 # access via ssh, rsh or similar shell into a file server.
 # 
 # This code requires that the template vfs (http://wiki.tcl.tk/11938) procedures
 # have already been sourced into tclsh.
 # 
 # Usage: Mount ?-volume? \
 #      <remote directory> \            # an existing directory on the remote filesystem
 #      ?-transport <protocol>? \       # can be ssh, rsh or plink
 #      ?-user <username>? \            # remote computer login name
 #      ?-password <password>? \        # remote computer login password
 #      ?-host <remote hostname>? \     # remote computer domain name
 #      ?-port <port number>? \         # override default port
 #      <virtual mount dir or URL>
 # 
 # examples:
 # 
 # Mount / -transport ssh -user root -host tcl.tk /mnt/vfs/tcl
 # 
 # Mount -volume /home/foo rsh://foo@localcomp
 # 
 # Mount -volume / -password foopass plink://foo@bar.org:2323/remotemount
 # 
 # The vfs can be mounted as a local directory, or as a URL in conjunction with 
 # the "-volume" option.
 # 
 # The URL can be of the form:
 # 
 # transport://[user[:password]@]host[:port][/filename]
 # 
 # Option switches can be used in conjunction with a URL to specify connection 
 # information; the option switch values will override the URL values.
 #
 # After a channel opened for writing is closed, if a file named ~/.fish_close
 # exists on the remote computer it will be executed as a shell script in the 
 # background (with the name of the file written as a command line argument), 
 # allowing post-write processing.  For example, .fish_close could be a script
 # that commits changes to a CVS repository.
 # 
 # client configuration:
 # 
 # The shell client must be in the PATH and configured for non-interactive
 # (no password prompt) use.
 # 
 # The value of the -transport option is assumed to be the name of a handler 
 # procedure which is called to handle the specifics of the particular client.
 # Handlers for the supported transports (ssh, rsh, plink) already exist.
 # New clients can be added simply by providing a suitable handler procedure.
 # 
 # server configuration:
 # 
 # The remote computer is assumed to have a bourne-type shell and the standard 
 # GNU fileutils, but otherwise no configuration is needed. 

----
[LV] Any thought of submitting this to the [tclvfs] project?

[SEH] -- I don't know what the submission process is, but I would be happy to see it included if the tclvfs maintainers are interested.

[LV] I suspect that if you visit the sf.net web site for the package, you should find
something like a web forum, mailing list, or feature request space for submitting
suggestions like this.
----
12nov05 [jcw] - There's not really a mechanism in place to submit/accept VFS drivers in the [TclVFS] project.
Would it be an idea to add VFS drivers to [tcllib], instead of creating a new area?
The question is really: is it ok to add [package]s to Tcllib which depend on TclVFS?
(given that TcVFS, or some rewrite of it, is likely to become more central in Tcl anyway)

[CL] thinks it's OK to add packages to Tcllib which depend on TclVFS.

CL in fact looks forward to it.
----
CL also thinks there'd be value in accumulating examples of interesting VFS usage, enough 
so to volunteer that ...
----
!!!!!!
%| [Category VFS] | [Category Package] |%
!!!!!!