[tahoe-dev] [tahoe-lafs] #840: Allow all CLI commands to take arguments from stdin or a file, to avoid caps being visible to other local users (was: Allow all CLI commands to take arguments from stdin or a file, to avoid caps being visible to other users)

[tahoe-lafs]

#840: Allow all CLI commands to take arguments from stdin or a file, to avoid
caps being visible to other local users
----------------------------------------------------------+-----------------
 Reporter:  davidsarah                                    |           Owner:           
     Type:  enhancement                                   |          Status:  new      
 Priority:  major                                         |       Milestone:  undecided
Component:  code-frontend-cli                             |         Version:  1.5.0    
 Keywords:  security confidentiality integrity usability  |   Launchpad_bug:           
----------------------------------------------------------+-----------------

Comment(by davidsarah):

 We're going to have to agree to differ about it being ugly to have to use
 aliases as a workaround for leakage of caps on command lines. To me,
 aliases are similar to variables in a programming language -- it's fine to
 create an alias/variable for something that will be referred to several
 times, or even twice, but you don't typically create a variable for every
 subexpression that is only used once. (Yes, I know there can be exceptions
 to that.) If a language or UI requires that, then it's imposing
 unnecessary mental overhead in forcing a programmer or user to choose
 temporary names.

 When caps become short enough to fit on a single line, so that they are
 more easily cut-and-pasteable, and are real URIs (#432 and other tickets
 listed there), this is likely to become more important in practice. For
 example, say that I receive a Tahoe directory URI in an encrypted email,
 and want to ''copy'' the contents to a local tree. I should be able to
 just do {{{tahoe cp -r @ dest}}} and then paste in the URI, without having
 to set up an alias that I may never refer to again. (If I did want to
 refer to it again, I'd go back to the email.)

 The {{{@}}} syntax is preferable precisely because it isn't an option
 argument -- it's metasyntax that gets substituted before any arguments
 have been parsed -- and therefore it shouldn't look like an option
 argument. For instance, I think the syntax {{{tahoe cp -r @ dest}} in the
 example above is less weird and easier to remember than {{{tahoe cp -r -f
 - dest}}}, which looks as though {{{-f}}} has the same status as other
 options like {{{-r}}}, rather than {{{-f -}}} being a substitution.

 {{{@}}} is also something that you could imagine becoming a more widely-
 used convention, whereas any option-like syntax would inevitably clash
 with other options and so could never become a convention.

 Replying to [comment:4 azazel]:
 > of course there is no need of using another syntax, a file containing
 just a line filled with command line options and arguments can be good
 enough, even if not so comfortable when there are many long arguments

 Given that arguments could be on separate lines (LF or CRLF would be
 equivalent to an argument separator), I don't think long arguments are a
 particular problem.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/840#comment:5>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid