[tahoe-dev] Fwd: [cap-talk] Don't put capabilities in argv?

[rob kinninmont]

On Jul 23, 2008, at 8:19 PM, Brian Warner wrote:

> On Tue, 22 Jul 2008 21:09:30 -0600
> zooko <zooko at zooko.com> wrote:
>
>> (Re-adding the cap-talk mailing list because they might be
>> interested in the general question of what sorts of command-line
>> tools could be invented to manage caps.)
>
> Since a common use case is going to be:
>
> tahoe mkdir   # prints out URI:DIR2:ovjy4yhylq:4d4f47qko..
> tahoe add-alias home: URI:DIR2:ovjy4yhylq:4d4f47qko..
> tahoe ls home:
> tahoe put stuff home:other-stuff
>
> We could just combine the first two steps:
>
> tahoe create-alias home:
> tahoe ls home:
> tahoe put stuff home:other-stuff

I'm definitely in favour of 'create-alias'
in fact I've always wanted that.
I don't think I've ever had an actual use for tahoe mkdir
other than to create an alias, and the process for that
  " tahoe add-alias name: $( tahoe mkdir ) "
always did seem a tad cumbersome.

>

another solution to the "don't put caps in argv" problem
that I've seen used in 'password' contexts in a few other
tools is to provide cmd-line options to read the cap from
a file.  similar to '-' or '--interactive', but reading
from a named file rather than stdin.

or perhaps framed another way, reading from a tmp file,
not using the alias mechanism.  to my mind the aliases
establish a long-lived, long term namespace of things
I care about.  using 'add-alias' to work around supplying
a cap in argv seems like the wrong solution - using a
long-term mechanism for a transient operation.

but that's just my 2 cents, or threppence perhaps.

cheers,
rob