Merge lp:~letterj/swift/st_stream into lp:~hudson-openstack/swift/trunk
Proposed by
Jay Payne
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Chuck Thier | ||||
Approved revision: | 119 | ||||
Merged at revision: | 129 | ||||
Proposed branch: | lp:~letterj/swift/st_stream | ||||
Merge into: | lp:~hudson-openstack/swift/trunk | ||||
Diff against target: |
91 lines (+29/-7) 1 file modified
bin/st (+29/-7) |
||||
To merge this branch: | bzr merge lp:~letterj/swift/st_stream | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Chuck Thier (community) | Approve | ||
clayg | Pending | ||
Review via email: mp+40679@code.launchpad.net |
Description of the change
Added "-o" option to the st tool
The option "-o <filename>" will send the object data to a file named <filename>
The option "-o -" will send the object data to standard out
Special Note: This option only works with a single file download.
To post a comment you must log in.
This is a great enhancement, nice work letterj. Also, you had mentioned some problems when you were setting up the branch, but I didn't have any issues merging these changes against trunk, very clean.
I found the help string for the -o option confusing at first:
"For a single file download stream the output other location"
I read it as "file download stream" - might be easier to read with a comma:
"For a single file download, stream the output to other location"
But I'm not sure about limiting all stream downloads to only a single file at a time? I think there's a use case for multi-file download to stdout (like if you want to pipe a stream of multiple log files to grep).
Whatever you want to do, I definitely think that we should return an error if the user supplies incompatible input (i.e. multiple file download single out_file filename) instead of guessing (i.e. silently ignore the -o option). Maybe you could add a test for it right at the top of st_download next to the "if (not args ..." bit?
Last thing, an implementation detail... I had to re-read the section at the top of _download_container where you're "inferring the behavior based on the length of the item coming off the queue" a couple of times before I got what was going on. That may not mean much tho, I'm kinda dense and tend to struggle with trixy python code, plus I'm not that familiar with st - so take this with a grain of salt - but I think it would be more readable to *me* if you just added an optional keyword argument to _download_container (i.e. http:// paste.openstack .org/show/ 140/)
Let me know if you have any questions.