On May 4, 2009, at 23:40, Zooko O'Whielacronx wrote: > If users had to cut and paste or back-tick-back-tick a cap onto the > command-line every time they wanted to access a directory, at least > they wouldn't mistakenly think that access was being stored somewhere > in Tahoe.
The problem with this is that argv is not private to users on Unix systems; so if you use a shared machine you absolutely must not ever transfer a cap by the command line. Yeah, it's lousy. If you want an dynamic-externally-provided-cap interface, take a filename and read it. Then /dev/fd names can be used for dynamic input, e.g. using bash <() for it. tahoe ls ~/mydir.cap (where mydir.cap is a file containing a tahoe cap) tahoe ls ~/mydir.cap/myfile (This is unambiguous but requires a bit of scanning to figure it out: If you have a pathname with a filename where a directory should be, then treat it as a file-containing-a-Tahoe-cap and take the rest of the path as the path within the Tahoe directory so named. Precedent: Subversion file: and svn: repository URLs work this way.) tahoe ls <(head -1 bunch-of-tahoe-caps.txt) (If you want to do some computation to get the cap, this is the way to do it. bash's <() connects a pipe to the stdout of the process in parens, gives the read end to an arbitrary fd in the top level process, and designates it by passing /dev/fd/N in the argument position where <() is.) -- Kevin Reid <http://homepage.mac.com/kpreid/> _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
