Use long versions of Drush commands instead of abbreviated commands

Thanks for the issue! That is an interesting suggestion: to use the long versions of Drush commands instead of the abbreviated versions.

I am not sure we really want to do that. If we did it in this one topic, we would probably want/need to do it in all topics with Drush commands. I agree that it would be more readable (to understand the commands), but in my own work, I normally want to learn the short version of the commands and use them, to save typing.

Thoughts from others?

Documentation should use the long version.

I am not sure I really agree with that. Why do you say that?

I guess my point is that most people don't learn or use the long versions of the commands, so I think we should use the short versions in our documentation.

EDIT: Though we should probably put a note in the Install Tools topic (where we introduce Drush) and explain that there are short and long versions of commands, and in the text, we provide the short abbreviations since that is what most people use, and probably we should put in some information on how to get help in Drush, if we don't already have that in there...

Most people who use drush regularly prefer to use the short version, as they know what they are doing.
People who don't use drush should read the long version, to have a bit of understanding what the command will do. When they are familiar with the drush commands, will probably switch to the short version.

I personally mostly use the long version as lately I am using the shell history to run drush migrate commands with too many parameters.

True about understanding the commands... Any other thoughts (from other people)?

As I remember back, in the documentations of other IT fields I also saw usually the full formats of CLI commands (mentioning their abbreviated forms only as nice-to-have option).

So I'd vote also +1 for the full (long) format.

I also think we should use the long / full version of the Drush commands as a standard. People soon enough learn that there are (shorter) aliases - they are always listed when you run "drush help some_command".

The full command show that the command belongs to a group of commands (that are used in "drush list"). So "cache:reset" is much better than "cr". And what about "cg" versus "cget" ... Which is "config:get" and which is "cache:get" ;-)

OK then, we need a patch that does this throughout the user guide. Updating summary.

I'm also a +1 for standardizing on using the full versions.

Hello, I'll be taking on this task to start contributing to Drupal documentation and get familiar with the tools/process. I'm also applying for Google Season of Docs shortly...

Are you still planning to work on this @acpkendo? If not, please set it back to "Unassigned". Thanks!

As there has been no response from acpkendo, I am currently unassigning this issue. Anyone (including acpkendo) who wants to work on it, please assign it to yourself. Thanks!

Here's a patch for this issue. I haven't tested the commands, but I am reasonably certain they're correct. I verified with grep that I updated all of the abbreviated Drush commands in the source/en directory.

Tested, patch #15 applies cleanly. Also checked that no commands are mentioned in the entire book for Composer, Git or other CLI tool, only for Drush, so it's easier to overview the changes.

Should we consider using the drush pm:enable command syntax instead of drush pm-enable. It appears that with Drush 9 both technically work. But it might be confusing because when you run a command like drush list the commands we are using in the patch above like pm-enable aren't shown.

Good idea. Since I don't have a Drush 9 working installed right now, could you attach to this issue a list of what you see using drush list? That would help me make another patch. Thanks!

You can find a list of the main Drush commands here https://drushcommands.com/drush-9x/

And, I've attached an updated patch.

Patch #20 applies cleanly and does the job nicely, thus RTBCing.

#20 is not quite done.

a) I found these lines with grep that still look like they have the old format:

config-uninstall.txt:drush pm-uninstall tracker
install-dev-making.txt:drush sql-dump > BACKUPFILE.sql
install-dev-making.txt:drush sql-query --file=BACKUPFILE.sql
install-prepare.txt:drush site-install standard --db-url='mysql://DB_USER:DB_PASS@localhost/DB_NAME' --site-name=example

Looks like those should be:
pm:uninstall
sql:dump
sql:query
site:install

b)

install-dev-making.txt:drush sql-dump > BACKUPFILE.sql

drushcommands.org suggests:

drush sql:dump --result-file=../18.sql

Also, so that the two patches don't collide, let's take #3086263: Maintenance mode command has changed in Drush 9 out of this patch? We can commit them at the same time...

Hm, actually no that won't work, because there will be context conflicts between these two patches also. Maybe best to combine them into one patch?

Another note: on this related issue, one of the comments states that the sql-dump > FILENAME command will not work, and you must use --result-file (as suggested in #22). So this becomes not a suggestion, but a bug fix.

Here's a new patch that updates the commands that @jhodgdon found with her grep-fu. As well as combines the fix for #3086263: Maintenance mode command has changed in Drush 9.

OK, this patch looks good. Committed. I'll mark the other issue fixed too.