I wanted to run a restore job from the command-line and started with
drush provision-restore --help
Restore the site to a previous backup. This will also generate a backup of the site as it was.
Arguments:
domain.com The domain of the site to be restored
site_backup.tar.gz The backup to restore the site to.
So I tried something like: drush provision-restore mysite.com ~/backup/mysite.com-1111.tar.gz
Could not find backup file mysite.com
So the argument domain.com is just wrong, ok next try.
I tried something like(cwd = the site directory): drush provision-restore ~/backup/mysite.com-1111.tar.gz
This gave the non-helpful error:
Backup directory does not exist.
What it should have been: drush @mysite.com provision-restore ~/backup/mysite.com-1111.tar.gz
It's obvious to me that the domein.com argument needs to be removed from the help. But how can we make it clear the a @mysite alias is mandatory?
The attached patch removes the domain.com argument and also adds an example which shows @mysite
It looks like the argument description has been copied to most of the provision commands... these should be checked.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | Selection_002.png | 14.12 KB | mig5 |
| #2 | Selection_001.png | 12.92 KB | mig5 |
| provision-restore_arguments.patch | 762 bytes | helmo | |
| provision-restore_arguments.patch | 762 bytes | helmo |
Comments
Comment #1
steven jones commentedYup, this one needs some attention.
Comment #2
Anonymous (not verified) commentedThe example looks a bit weird in my tests, I think we are hitting some sort of Drush CLI styling issue where the actual example code wraps, and it looks as though the 'description' carries along the same line.
Not sure what we can do about it really.. I guess the (correct) example code is just too long..
Comment #3
Anonymous (not verified) commentedThe other thing is, basically *all* provision commands need the context's alias name prefixed.. not just this one. So we'd either be obliged to provide examples for *all* (not that bad an idea, if we can get it to look ok), or none..
Comment #4
Anonymous (not verified) commentedWe'd have to increase the drush_print_table in drush_print_help() to 60 chars (from 40) - not sure Drush developers would put this in just so our help commands look nicer :)
Comment #5
Anonymous (not verified) commentedMaybe it's just my 12" thinkpad screen. See #1005816: Improve readability by wordwrapping long messages
Comment #6
steven jones commentedThe wrapping is a drush problem, I think as long as we've provided a decent example then if drush then decides to format it badly, it's not our fault!
(This can totally happen in 6.x-1.x, so updating branch)
Comment #7
helmo commentedI've noticed the ugly wrapping of examples, but as you point out that's a different issue.
Adding examples for all commands would be good, but removing the false information about the 'domain.com' argument is more important to me.
Comment #8
helmo commentedComment #9
Anonymous (not verified) commentedyep agreed. I've pushed this commit, thanks! Will add other examples to the other commands separately soon.
Comment #10
Anonymous (not verified) commentedIt turned out that many more help commands used the 'domain' argument too and other args such as platform paths etc (provision-migrate, provision-clone)
I've now updated all of them and added examples for them all too, that show the @alias prefix.