#114 assigned enhancement

command-line: multiple files at once

Reported by: zooko Owned by: zooko
Priority: minor Milestone: undecided
Component: code-frontend-cli Version: 0.7.0
Keywords: tahoe-cp usability Cc:
Launchpad Bug:


It would be nice if "allmydata-tahoe put a b c d e/" would put the "a", "b", "c", and "d" local files into the "e" virtual directory.

Change History (15)

comment:1 Changed at 2007-08-17T22:28:09Z by zooko

  • Status changed from new to assigned

comment:2 Changed at 2007-08-20T18:02:14Z by zooko

This is part of the "improved command-line" task. I would like to see it done for v0.6.

comment:3 Changed at 2007-08-20T18:55:29Z by warner

  • Component changed from unknown to code-frontend

comment:4 Changed at 2007-09-19T22:58:54Z by zooko

  • Milestone changed from 0.6.0 to 0.7.0

comment:5 Changed at 2007-10-19T23:15:26Z by zooko

  • Milestone changed from 0.7.0 to 0.6.2
  • Version changed from 0.4.0 to 0.6.1

I'm interested in working on a few tickets which all have to do with improving the cmdline, for v0.6.2. This is one of them.

comment:6 Changed at 2007-11-01T18:08:59Z by zooko

  • Milestone changed from 0.6.2 to 0.7.1

We're focussing on an imminent v0.7.0 (see the roadmap) which hopefully has #197 -- Small Distributed Mutable Files and also a fix for #199 -- bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

comment:7 Changed at 2007-11-13T18:29:42Z by zooko

  • Milestone changed from 0.7.1 to 0.7.2
  • Version changed from 0.6.1 to 0.7.0

We need to choose a manageable subset of desired improvements for v0.7.1, scheduled for two week hence, so I'm bumping this one into v0.7.2, scheduled for mid-December.

comment:8 Changed at 2008-01-15T21:37:50Z by zooko

  • Component changed from code-frontend to code-frontend-cli

comment:9 Changed at 2008-01-23T04:21:43Z by zooko

  • Milestone changed from 0.7.2 to undecided

comment:10 Changed at 2008-06-01T21:48:19Z by warner

this ought to true for "tahoe cp a b c tahoe:dir/", where a b and c are files. They can be directories if you add --recursive.

I'm currently thinking that "tahoe put" and "tahoe get" should be explicitly single-file.

comment:11 Changed at 2009-12-13T03:58:19Z by davidsarah

  • Keywords cp usability added

wontfix (for put/get)?

comment:12 Changed at 2009-12-23T19:51:44Z by zooko

Brian: why do you think tahoe put should be explicitly single-file? For that matter, what is the difference between tahoe put and tahoe cp nowadays? I must admit I don't use the cli much. The existence of the aliases vaguely offends my taste because I think that it "ought" to solved with a combination of tahoe-lafs caps and unix utilities instead of with tahoe-lafs aliases.

I should probably use the cli more. But anyway, why does tahoe get exist if tahoe cp can do everything that tahoe get can do and more?

comment:13 Changed at 2009-12-23T21:10:34Z by davidsarah

As a new user, my impression was that tahoe cp was the more flexible and preferred way of doing things, and tahoe get/put were just there for backward compatibility.

Part of #856 is to improve the tahoe --help text. Please make suggestions in that ticket as to how get and put should be described.

comment:14 Changed at 2009-12-24T21:59:58Z by warner

I think of "tahoe put" and "tahoe get" as the primitives: data-to-cap and cap-to-data, nothing else. In explaining how tahoe works, you need these CLI tools for the first set of examples, and I use them in practice for sharing files from the command line (when I'm not sharing files through the WUI). I don't actually use their "copy-to/from-directory" forms very much.

"tahoe cp" cannot upload an unlinked file: the target must be a directory or a filename that exists as the child of some known directory. "tahoe cp" is much more familiar to unix users, since it works like /bin/cp or scp, so I expect more people to use "tahoe cp" in regular practice.

I think that "tahoe cp a b c d:" is a good, easily-understood way to copy multiple files into a single target directory, and I think that changing the syntax of "tahoe get" and "tahoe put" to accomodate variable-length argv arrays would make them harder to understand, so on the whole, I think that get/put should be single-file and cp should get the job of handling multiple files. Maybe we should make this more explicit by removing the alias/subdir-handling features of get/put and making them strictly cap-to-data and data-to-cap (i.e. "tahoe get FILECAP >localfile", "tahoe put localfile", and "cat localfile | tahoe put").

And yeah, the tahoe --help text on all of these can probably be improved a lot. I'll take a look at #856 and see what suggestions I could make.

comment:15 Changed at 2010-02-12T05:08:57Z by davidsarah

  • Keywords tahoe-cp added; cp removed
  • Milestone changed from eventually to undecided
Note: See TracTickets for help on using tickets.