[policy, no patch] Decide naming the new CLI entry point to dr

How about drush? It has a nice ring to it :)

drop would also be a nice touch.

Thank you for creating the follow-up.

I reparented this under the meta: #3582246: [meta] CLI in Core community initiative for tracking.

For those who search for drush commands, applying recipes, and quickstart today, what are the common search terms that are used? Is this something that we can get from the drupal.org infrastructure team?

I wasn’t gonna say anything, but I am in favor of…Drush.

That’s been the Drupal shell for 20 years. We know it and love it and it’s everywhere. Is there a reason it can’t just be our old beloved Drush?

Historical naming from 2911319: comment #158 concluding about #174 or so (with various other topics being discussed).

Summary: we all fell in line with alexpott’s suggestion and preference to use drupal because drupal.sh had been around for ages so there was precedent for keeping the name the same. Note the name clash with console no longer applies for Drupal 11+.

I propose `drup`. An obvious shortening of drupal, yet there's no existing d.org project. Memorable, easy to type and pronounce. I think this will make it easier for folks to discover, learn, and communicate in shorthand (avoid "which drupal are you talking about?" confusion).
If you need it to have a backronym, there's "Drupal runtime utility program" ...or "Drush replacement utility program" if you're nostalgic.
Bonus: "drup" in Dutch appears to be a colloquial short form of "druppel" (I think it's "drip" vs "drop"?)

'drux'

Besides being loosely recalling 'drupal executable', it's also resonating with Asterix and Obelix, who were Gauls like Drupal's originators (if I understand correctly) 😊.

OK, don't take this too seriously...

If we are starting fresh, I’d argue for making dr the official command for Drupal-CLI and designing everything around it. It’s short, lightweight, easy to type with one hand, and feels like a natural evolution from Drush and Drupal Console. Tools like WP-CLI (wp) and GitHub CLI (gh) show how much consistency and adoption you get when the short form is the actual interface, not just an alias. It becomes muscle memory quickly, and the whole ecosystem aligns around it, including docs, scripts, code examples.

Drupal has more history to account for, but IMO dr is the cleanest long-term path. It’s close enough to Drush to feel familiar, while simple enough to signal a reset. There’s no meaningful namespace collision, and it matches how devs already work: short, fast commands without relying on local aliases. A shorter command reduces cognitive overhead and fits better across docs, scripts, and constrained spaces like IDE terminals and AI-sidebar chats. If the goal is a first-class, modern CLI, committing to dr aligns the interface with how it will actually be used.

When looking farther afield, there actually aren’t that many true 2-character CLIs. That’s what makes them powerful: highly intentional to become the primary interface (not just a wrapper), signals confidence and maturity, unique namespace backed by strong ecosystems, no alias needed, Docs reinforce the short form, results in high adoption.

WP-CLI => wp
Angular CLI => ng
GitHub CLI => gh
Azure CLI => az
Golang => go

Most tools land in:

3–6 chars (npm, sass, ddev, cargo, lando, drush, docker, drupal, gcloud, upsun)
or long names + unofficial aliases (terminus, terraform, platform, kubectl, ansible-playbook)
or worse: php bin/console (symfony), php artisan (laravel)

By choosing dr we have a singular opportunity to use a unique key sequence and namespace to our advantage and build for typing speed, brevity, clarity, and through strong muscle memory gain a faster adoption rate (and perhaps even increased enthusiasm and contribution rate).

Awesome. Glad the idea landed well. I took a few liberties updating the IS liberally to advocate clearly for dr. Hopefully I havent overstepped or offended anyone's other idea.

In order to implement the change there are a few options with various drawbacks:

1. Maintain two copies of the script, bin only one, for backwards-compatibility despite drupal being internal. This makes it harder to maintain until removal in N years and could be confusing for the minority that use the script now.
2. Write a composer plugin that renames the vendor’d script (post-install/update?). This adds more code to maintain long-term.
3. Rename core/scripts/drupal to core/scripts/dr without deprecation because it’s internal and deal with the fallout of mainly core developers, but also recipe developers now who are using the existing commands.

I'm unsure of the specifics around what is currently in progress. Is the vendored thing a copy of the original file, a symlink, a thin wrapper, or something else? Could the file itself be core/scripts/drupal-cli for extreme code- and maintenance-clarity and then what gets vendored and therefore documented and used widely is vendor/bin/dr?

@jwilson3, the file that is bin’d is a thin wrapper or proxy with file I/O helpers that is written into the directory provided via bin-dir (default: vendor/bin). There is no mechanism to rename or alias bin'd files, and that feature won’t be implemented in composer itself. The file name is always the same.

#13 can core/scripts/drupal just call out to dr (or if that's not possible, just be an exact copy of it) but issue a deprecation notice up front? Then we can remove it in a future major.

@longwave Good point. It does not need to be an exact copy like I thought. I think the following would work.

/**
 * @file
 * Provides CLI commands for Drupal.
 *
 * @deprecated in drupal:11.4.0 and is removed from drupal:13.0.0. Use the dr
 *   command instead.
 *
 * @see https://www.drupal.org/node/3584928
 */

declare(strict_types = 1);

@trigger_error('Calling drupal is deprecated in drupal:11.4.0 and is removed from drupal:13.0.0. Use dr instead. See https://www.drupal.org/node/3584928');

return include __DIR__ . '/dr';

Renamed to dr incorporating #17

Slightly confused. This issue is to bikeshed the name that will be implemented in #3453474: CLI entry point in Drupal Core? Seems like we agreed on dr at this point. Can this issue be closed?

Saved credit for everyone who participated.

I think that this is still Needs review to give more time for people to review dr and the argument in favor of dr.

It is not difficult to switch the name of the command in the merge request for #3453474: CLI entry point in Drupal Core if it needs to be done.

dr and pal are both strong contenders.

dr is nice because it's two letters, I really like the idea of having a pal to help me though. I think it lends itself to anthropomorphizing which could help with marketing it as a tool.

Three letters isn't that much worse than two. The other thing to test is repeated typing since it will be frequently typed out, they both seem about equal from that perspective.

I lean towards pal

Tab completion noise perspective: before `pal`, the stock install already lands 7 binaries in vendor/bin that start with `p` including one that starts with `pa`. Zero competitors for `d`.

+1 to dr

Thank you for your run through of strong arguments @jwilson3, which I agree with:

dr is a great choice.

Minor argument against dr: issue search in d.org is restricted to at least 3 chars. Mitigated by (hopefully) having a "Component" in issues to filter with.

I don't feel super strongly. I don't love drupal for this, but could be convinced. I would probably end up aliasing that one.
dr is not just shorter, but way easier to type (1-hand, 2 keys right next to each other, both on the same side of the keyboard). pal needs both hands, all the way across the keyboard between each key. So I lean towards dr, but I won't die on this hill. pal would be okay.

D.o issue search is going away in O(months). Drupal core issues might be on GitLab before we even hit Phase 2 of this initiative, perhaps even before Phase 1. So I don't think that's a good reason to avoid dr.

So what's needed for this ticket? Documented anywhere.

Re: #34: Good point about formally identifying co-maintainers. See #3590536: Add a MAINTAINERS.txt entry for Drupal CLI

I'm not sure we need all the formal core governance sign-offs for this. Seems from the initiative Slack meetings that everyone involved is okay with dr. Tempted to move this back to RTBC, but we can leave it NR for now.

Adding [policy, no patch]. I think we just fixed this before without RTBC since the changes were already made.

The existing CLI commands do not have a separate topic or area in maintainers.txt, but I think each command falls under their respective maintainers (recipes, cron (no maintainer)).

So can we mark this fixed?

Going to put into RTBC if there’s anything from a governance stand point else this just can be marked fixed I think and release the credit to those

This might be late. But how about commander name? This is more semantic then dr.

Just want to voice my support for dr based on #10 after I previously argued in other places against pal before this issue was opened.

It's short, I can easily type it with one hand: dr dr dr dr dr dr dr dr dr dr dr dr dr dr dr dr dr and I think all the two letter examples given are memorable and look great in examples, which want to focus on what's different (the command executed) over what's the same between examples (the name of the CLI):

dr site-install <options>

So lets make dr as ubiquitous as commands like gh.

WP-CLI => wp
Angular CLI => ng
GitHub CLI => gh
Azure CLI => az
Golang => go

Worth noting: ng is something like an alias for the Angular brand. They use ng everywhere, from prefixes in HTML attributes to conference names. The same applies to wp and gh.

As for go, it just happens that the language name consists of the two letters "Go". Unlike these, dr is not an alias for the Drupal brand.

Btw, if we want to stick to two letters, we also consider the dp name.

As a product manager I think dr is fine.

dr seems fine to me too, looking forward to typing dr cr let's go ahead and mark this fixed to unblock adding it.