Support for multiple file names to upload..

[wvmarle]

WARNING. This patch adds support for multiple file names, and changes overall behaviour a bit.

Now works like: glacier-cmd <upload> <vault> <filename> <filename> Also can accept wild cards in the file names; it is expected that the shell will expand wild cards before the options are passed on to the script (does Windows do this? If not we have to check for presence of wild cards and expand ourselves using glob.glob()!)

Positional argument description is now an optional argument --description DESCRIPTION, this to allow for multiple file name arguments. And actually it makes more sense as it is an option.

Added --bacula switch; if used the (must be a single argument in that case) is expected to be Bacula-style for multiple file names, and parsed accordingly.

Files are handed to GlacierWrapper's upload routine one by one for uploading.

Made some changes in the filename/description for the bookkeeping when using stdin: file name defaults to "Data from stdin." and description to "No description."

[offlinehacker]

Nice, glob is awesome :D On Oct 9, 2012 8:03 PM, "wvmarle" notifications@github.com wrote:

WARNING. This patch adds support for multiple file names, and changes overall behaviour a bit.

Now works like: glacier-cmd Also can accept wild cards in the file names; it is expected that the shell will expand wild cards before the options are passed on to the script (does Windows do this? If not we have to check for presence of wild cards and expand ourselves using glob.glob()!)

Positional argument description is now an optional argument --description DESCRIPTION, this to allow for multiple file name arguments. And actually it makes more sense as it is an option.

Added --bacula switch; if used the (must be a single argument in that case) is expected to be Bacula-style for multiple file names, and parsed accordingly.

Files are handed to GlacierWrapper's upload routine one by one for uploading.

Made some changes in the filename/description for the bookkeeping when using stdin: file name defaults to "Data from stdin." and description to

"No description."

You can merge this Pull Request by running:

git pull https://github.com/wvmarle/amazon-glacier-cmd-interface master

Or view, comment on, or merge it at:

https://github.com/uskudnik/amazon-glacier-cmd-interface/pull/74 Commit Summary

• Added support for multiple file names and wildcards in the file name.
• Final fixes.
• Updated documentation to reflect new developments.
• Merge branch 'development' of git://github.com/wvmarle/amazon-glacier …

File Changes

• M doc/Usage.rst (22)
• M glacier/GlacierWrapper.py (39)
• M glacier/glacier.py (76)

Patch Links

- https://github.com/uskudnik/amazon-glacier-cmd-interface/pull/74.patch

• https://github.com/uskudnik/amazon-glacier-cmd-interface/pull/74.diff

  — Reply to this email directly or view it on GitHubhttps://github.com/uskudnik/amazon-glacier-cmd-interface/pull/74.

[wvmarle]

Just added glob and expanduser for those situations where the shell hasn't done this yet (e.g. being called not via shell or so).

[wvmarle]

3957fdc : adds wild card and ~ expansion to input files (in case shell doesn't do this yet). 522788f : in DEBUG mode when uploading stuff, boto would write the complete upload data (every GB of it) in the log file! This switches boto logging to INFO level if it's lower than INFO level. cd3ee80 : add error numbers and exit codes that depend on errors (should settle issue #5).

[uskudnik]

Should I just merge this or do we wait a few days, maybe a week since we are changing arguments?

[wvmarle]

Yes, arguments are being changed, not my favourite action either. It's just the only way to handle wild cards and as I said it kinda makes sense to me as it's optional already.

For command line arguments maybe it's a good idea to have a good hard look at what there is now, see if anything could/should/might be changed, do it, and then call that interface final and move on to a 1.0 release.

[uskudnik]

Sounds like a good idea... Probably best to open a new issue On 10 Oct 2012 21:16, "wvmarle" notifications@github.com wrote:

Yes, arguments are being changed, not my favourite action either. It's just the only way to handle wild cards and as I said it kinda makes sense to me as it's optional already.

For command line arguments maybe it's a good idea to have a good hard look at what there is now, see if anything could/should/might be changed, do it, and then call that interface final and move on to a 1.0 release.

— Reply to this email directly or view it on GitHubhttps://github.com/uskudnik/amazon-glacier-cmd-interface/pull/74#issuecomment-9315777.

[wvmarle]

Instead of printing to a table on the screen, user can now select json or csv type output. The output will be dumped on stdout, so need a simple redirect to get it into a file. Easier than coming up with an outfile option which clashes with the file download function...

New switch and config file option: --output [print, json, csv] (default: print, which is the current tabular output).

[wvmarle]

Download works once again; now in part mode, downloading part by part. Added the same progress bar as used for uploading files.

Download resumption not implemented yet but shouldn't be too hard to do now it's downloading parts.

[uskudnik]

Do add the warning to the release notes section please, possibly even highlighting the difference before and after.

[wvmarle]

Done. Updated release note is in the merge patch above.

[uskudnik]

I was going through the code and I found something that I'm not sure of whether it's a bug or am I missing something out?

https://github.com/wvmarle/amazon-glacier-cmd-interface/blob/0c8b0cfe619a2e5229f66aa66a859f05223c570e/glacier/glacier.py#L423

Doesn't this default override users configuration file if he has it in ~/.glacier-cmd? Might be me missing something out since I didn't do this so I would rather check with others before fixing it.

(EDIT: In retrospective and since it's present in master as well, I should probably open an issue...) (EDIT 2: Just the message is wrong.)

[wvmarle]

The help message is wrong.

help="Name of alternative config file."

Come to think of it: if the user supplies a config file, shouldn't we use ONLY that file? A config file may not have all possible keys present, in which case values from other config files may be used to fill in those keys. This may be undesirable behaviour.

Solution: check whether args.conf has a value; if so use that and only that, if not try the two hard-coded config files.

[uskudnik]

Since its weekend, this seems like an appropriate time to merge such a pool request :D