[tahoe-lafs-trac-stream] [tahoe-lafs] #166: command line order is problematic

[tahoe-lafs]

#166: command line order is problematic
-------------------------+-------------------------------------------------
     Reporter:  zandr    |      Owner:  warner
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  1.10.0
    Component:  code-    |    Version:  0.6.1
  frontend-cli           |   Keywords:  security usability unix mac error
   Resolution:           |  review-needed zookos-opinion-needed
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

> allmydata-tahoe put -u http://localhost:port LOCAL_FILE REMOTE_FILE
>
> Assuming we're going to have to specify the -u at all (can we stash that
> in ~/.allmydata or similar?), it seems that options that are generic
> regardless of the command should be *before* the verb.
>
> This is made more annoying by the fact that the usage/help specifies "put
> LOCAL_FILE REMOTE_FILE" with no meniton of -u, and the error if you get
> that wrong is an unhelpful "wrong number of arguments."

New description:

 allmydata-tahoe put -u http://localhost:port LOCAL_FILE REMOTE_FILE

 Assuming we're going to have to specify the -u at all (can we stash that
 in ~/.allmydata or similar?), it seems that options that are generic
 regardless of the command should be *before* the verb.

 This is made more annoying by the fact that the usage/help specifies "put
 LOCAL_FILE REMOTE_FILE" with no meniton of -u, and the error if you get
 that wrong is an unhelpful "wrong number of arguments."

--

Comment (by Zancas):

 I believed that I could pass options to the tahoe utility instead of its
 subcommand so I attempted to run:
 {{{>tahoe -d /home/arc/myLAEgateway/ backup /home/arc/sandbox/KandRC/
 KandR:}}}
 which failed (with an ugly traceback).

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/166#comment:30>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage