support tilde expansion of home dir in --destination target

It is the shell, not the script or application that does tilde expansion. The shell does not expand tildes mid-parameter. As a workaround, use drush dl --destination=$HOME/.drush provision-6.x.

Setting status to support request / fixed for future FAQ purposes.

I think there's a potential argument here that maybe destination should be the last argument instead of an option.

It would take care of this issue while following an example already set by SCMs.

The argument list for dl is a list of projects; it is always a bit tricky dealing with ambiguity when arguments may be of different types, so this is generally a deprecated practice. For example, drush dl foo bar could mean "download foo and bar" or "download foo and put it in directory bar". In this case, it would be possible to disambiguate between a project and a destination based on whether or not the parameter contains a slash. I am not particularly enamored of this solution.

Another thing that is supported in the shell would be drush dl --destination ~/.drush provision-6.x; however, supporting this generally in drush would be problematic. Drush already supports --option (with no value), and having drush start associating an argument value with these sorts of options would have potential compatibility issues.

It might be possible to support a hybrid of these two techniques; --destination with no specified value could cause pm-download to find an argument with a slash in it to take as its value. It would not be possible to have --destination take the argument immediately after itself, though, as drush separates args and options into separate maps, so positional information is lost.

If we did #996092: Better handling of unknown option, then we could also attach a flag to the option that specified whether its value was required, optional or disallowed. Then, --destination ~/.drush could be supported in this model.

However, it is overall my fear that mixing --option=value and --option value in drush would introduce confusion over basic command syntax, and I don't think it's really worth it.

--destination is a "standard" for several commands and those commands can have variable number of arguments. i don't think an arg will fly here. blame php for not supporting named arguments to functions.

... and why don't we just expand ~ within drush exactly, since the shell doesn't do it?

Also, the "classic" way of handling commandline arguments is to have:

--destination=foo

and

-d foo

... to remove the ambiguity... (?)

While single-dash options do usually behave as you describe, the main difference between -o and --option is that the single-dash variety is single letter, and can be combined, e.g. -ravz == -r -a -v -z. The single-letter restriction of single-dash options means that you run out of them fairly quickly, and -d already means 'debug'. Because most of the single-letter options are already taken with parameterless options, I think that it might be a little late to introduce this concept into drush.

I suppose we could introduce a drush_get_file_option() command that did ~ expansion...

Sounds like we should do just that (expand ~ ourselves). :)

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.