It's certainly my fault, but I was wanting to chack up on some options, and went:

drush --help

... and that got me some hints, but then I went :

drush --help dl

which is wrong but not crazy.
So expected scenario - I get some help text.
Worst-case scenario - I get told off for not asking correctly (drush help dl)
actual result - an entire checkout of Drupal core was installed into my current working directory!!
Wha?

I get that it's sorta a convenience to let drush dl assume that you want a brand new everything (really?) but this was a bit cavalier.
I call it a UI WTF, and would suggest you are required to at least say drush dl drupal for this process to kick in!

... Yes, it was technically my mistake by getting my options confused, but y'see what I'm saying?

(turns out that I got the first result by accident, but I got exactly what I asked for, so there was nothing wrong there)

Comments

moshe weitzman’s picture

OK, then do rm -rf drupal and you done. lesson learned. I don't see a problem, personally. Lets hear what others think.

dman’s picture

It's not tragic or anything, it's just that I guess almost every other commandline tool I'm familiar with will put on the brakes and say "hey, that word - I do not think it means what you think it means" when you offer it invalid input.

Seeing as I clearly meant something else, expected behaviour is to not do something unintended and potentially damaging rather than just go "he doesn't know what he's doing, let's surprise him!"

This is not just about me slipping up on the options with this one command, it's about the tool not validating its input is valid. Looking at getopt(), I see that is just normal, and unexpected input is just discarded. Which can make sense, and is indeed easier and more flexible.

But looking at common tools like cvs, tar, ssh, rsync and I-don't-know-how-many others, feeding it an invalid option results in either an error and an abort, or a usage/help display.
Maybe it's a style choice, and maybe power-users just never ever make mistakes or experiment, But I find the tools that have those safety guards built in are basically more robust, and friendlier to learn (not just use, learn). In a config file, or in a commandline, I'd rather the system told me I got it wrong (so I could fix it) that let me assume my voodoo was just working.

Heck, I know that in development it's (a lot) easier to allow for unknown future options to slip through like this. I'd probably engineer it like that myself (have already, in fact). Until I learnt this lesson I learnt today. I guess there are different approaches for different uses. I'm just throwing this gotcha out there for thought.

seanr’s picture

Category: feature » bug

I'm with dman on this - standard convention on Unix/Linux systems seems to be to put --help as a switch on a command. I would've expected the same thing he did, and I actually have used drush --help a number of times (just never tried drush --help dl). Maybe the more appropriate command would be drush dl --help, but nevertheless, I wouldn't expect it to download anything if I had the help switch in there somewhere.

moshe weitzman’s picture

OK, we can easily support --help as an equivalent of drush help. Patches welcome.

moshe weitzman’s picture

Status: Active » Fixed

Committed a change where we force help command if --help was specified. I rather like it. For now, this is undocumented. The documented method is to call help command not help option. I don't mind documenting both on the main help page, if folks think thats more helpful than confusing.

Please open new issue if folks still want to remove assumption of 'drupal' when drush dl is run without further arguments.

dman’s picture

Cool enough. I just need to read a bit more carefully and make less assumptions I guess! I can see that drush dl is pretty nifty shorthand, but it was odd (to me) that the biggest and rarest thing you'd ever do with the tool was the the shortest command available.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.