# 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 packages 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 ...
