"drush cli" supported in drush-3.0.

Thanks for the notice but if I dropped my own development about this shell, this is for the very reason I found more efficient not to follow the "sub-shell" path. For me, subshells will never be the right_shell_for_everyone and will always reduce possibilities and introduces caveats.

As an example (no critic here, just example), with the RC4 CLI :
- it can't load local script (using "source script" or ". script")
- it lost autocompletion because on any unix system you more that 200 commands beginning with 's' (when searching to complete the drush command "status").
- it lost (this can be solved) master bash settings (like all previous macro)
- it's conflicting with native commands (how do I do a realy rsync when drush also have a rsync command...)

I speak quietly about the dead-end of this new feature as I figure this out for my own shell. Drush is a great tool but I definitely think that "drush cli" is not the way to go.

I really don't wont to be boring about this, but the more I think about this, the more I'm convicted drush-cli will bring more problem than solutions. I just had an other situation when speaking with people on my web site about the power of ZSH compared with Bash (an article about implementing custom auto-completion with bash). At the end of the day, it's all matter of tastes, by the fact is that bash is not the only shell in the arena and your cli implementation will have to be compatible with all of them as you just can't tell people "ok, now you're in a drush subshell now, forget about you zsh or whatever, you'll love bash again, I promise " ;-)

Each bash provide solid auto-completion kind of API, local functions, and all features needed to provide a nice drush experience. On the drush side, the only miss is a set of functions to provide informations to *sh functions (ex. list of commands, parameters for a command, etc...) in order to bring drush auto-completion that drush-cli is actually missing. In my own shell-bash binding, I had to add a some of those custom commands in order to make the magic work and they are so simple.

So why not providing drush-cli as a module and integrating such "API" *sh commands in the core ?

To be more precise on my last suggestion, in order to implement a simple auto-completion plugin for bash, I needed to make a drush plugin like this :

function drush_drush_extension_ds_commands() {
  $commands = drush_get_commands();
  foreach ($commands as $name => $command) {
    echo $name . "\n";
  }
}

// FIXME Need some cache here...
function drush_drush_extension_ds_modules() {
  $modules = drush_pm_get_projects();
  foreach ($modules as $name => $module) {
    if ($module->type == 'module') {
      echo $name . "\n";
    }
  }
}

function drush_drush_extension_ds_module($module_name) {
  $modules = drush_pm_get_projects();
  $module = $modules[$module_name];
  echo dirname($module->filename);
}

With those new commands, i'm able to complete drush commands, but also some command arguments (ex. drush en [tab]). I think this would be interesting for such commands to be directly in core.

But perhaps better option, would be to add completion behavior directly to drush command. The same way you have a drush hook for commands help, you can imagine kind of drush_auto_complement hook, that will permit each command author to provide list of possibilities in every situation. Something like :

function example_drush_auto_complete() {
  $args=func_get_args();
	
  switch (count($args)) {
    case 1:
      return array('sub-command1', 'sub-command2');

    case 2:
	switch ($args[1]) {
		case 'sub-command1':
		      return get_list_of_enabled_modules();
		etc.
	}
	break;

  etc...
  }
  // null returned => northing to auto-complete
}

This way, implementing auto-completion for each shell should be quite easy.

Hi Greg,

In order to be more pragmatic, I wrapped my "drush completion hook" as a drush module and updated this project page with explanation. If you don't mind, could you have a look and giving me your feedback ?

For completeness, #543550: Drush interactive mode was other attempt to implement a drush shell. The idea there was to be able to enter a (real) drush shell based on php and readline (#562888: The readline library) to autocomplete drush commands and even more relevant to me: the possibility to run commands within the same bootstrap process.