drush site-alias should indicate the current alias set by drush use

There is a __drush_ps1() function in drush.complete.sh that you can add to your PS1 to show your active site alias right on your prompt.

I think that patches that add git-style active indicators (prefix each line with "* " or " ") would be considered favorably.

I think this is okay with the addition of the suggested documentation. I'd also be okay with the "-" on the previous alias, if desired.

This should be reworked once #1866344: Make --pipe awesome with output format engines lands. The other alias marker should be placed one of the table columns, and the default format should be table. Other format types should be supported.

I'm tempted to just close this and fix it with #1866344, but will keep it open for now.

[ #1866344] has landed. I guess work here can proceed? I agree with the initial suggestion for folks to customize their bash prompt. It is really the best way.

If you run drush sa --format=table on the latest 8.x-6.x-dev, you will get a tabular output with fields for the alias id, root, uri, host and user (the last two for remote aliases only). This table is too wide for most terminal windows, and probably would not make a good default format.

It would be easy enough to add a new field to the site-alias command that indicated the last and next-to-last aliases used. I think that "*" for the last alias and "-" for the next-to-last (with empty for the others) would be just fine.

I'm not sure what the default format should be for the sa command, but if you made the default format 'table' and the default fields the last-alias marker and the alias ID, that would give a result in line with what was suggested previously. If you then ran sa with the --full option, you'd get more fields, in line with the current --format=table output, so I think that would probably work out.

@Benji - Care to implement #10? This requires some knowledge of output formats. Would be great if you and others became familiar with this new system.

Unassigning. I'll help answer questions; see drush topic docs-output-formats for an introduction.

3. I think that field-mappings is a lookup instruction. see its usage at http://api.drush.org/api/drush/includes!output.inc/function/drush_rows_o...

1. I don't that it matters much where this line is. Go ahead and move it if you wish.
2. This is controlled by the 'fields-default' key in the command definition. I confirmed by addeding uri to this array and then --format=table started printing out the uri from a site alias. Arguably that should be in the default fields.

site-alias command gets slightly complex with outputformat because it does two things depending if an argument was provided: list or detail. This is a common pattern - see test-run, watchdog-list/watchdog-show, queue-list/queue-run, and views-list/views-execute. Maybe we should add a site-list command and require folks to use that for site alias listings? If we go that route, it makes sense to split our part of test-run into a new test-list command.

Thoughts?

Right now, site-alias in default (list) mode is a lot slower than it needs to be, because the site-alias command does not know (does not check) how its output format will handle the data. In list mode, only the array key is needed, but the full data structure is produced, because the implementation is very general-purpose. If we had a site-list command, it could execute more effectively.

Despite that fact, from a UX point of view, I wouldn't really want to have a bunch of *-list variants for all commands that are like this. If we did implement the commands like this for performance reasons, maybe we could intelligently have the command dispatcher switch from the 'site-alias' command to the 'site-alias-list' command (which is aliased to 'site-list' and 'sl') iff the selected output format is a simple list.

Just thinking aloud; not sure of the best solution.

I like the command dispatcher approach. I think site-alias-list could be a hidden command. I can take this on. If this turns out well, we'd want to unify those other commands I mentioned on the same approach.

@benjifisher - sorry to hijack your issue a bit. feel free to continue mulling how we implement the site-set marker and what the default fields should be for a listing.

I don't think we can speed things up here. We want the ability to show a table or csv for a listing that has root/uri etc.

So, I started to implement the original feature request here and ran into a snag. When you have used site-set, all your commands are targetted to the remote site - even site-list! So, you won't ever see a site marked as being active. We could probably force sa command to always operate locally, but I don't think thats wise.

When I was testing this, I once again smiled as my bash prompt told me what site was active. I really encourage folks to source our drush.complete.sh script and then use the __drush_ps1() function in their PS1. This is documented in the README.

Not sure there is anything more we should do here.

Hm, yes, it would be easy enough to flag the site-list command to always run locally, like ssh does. I think that overall that would be a big improvement, but it would be a source of frustration to anyone who actually did want to run the site-list command remotely, to see what sites are defined on a different machine.

Maybe what we need here is a command-exception list for site-set, so that site-list runs locally when you've set the site to a remote machine, but you can still use drush @remote site-list to inspect the aliases on the remote machine.

It would be good if this level of functionality were supported if we implement the proposal in this issue. I agree that relying on __drush_ps1 works well, and sidesteps the oddities with site-list nicely.

Too complicated. I'm back to recommending the custom prompt.

Fine by me. I can't think of another command that would want to use the facility described in #22.

#25 does look like a bug; you are correct that drush use should always run locally. Please note that we already have a facility to set certain commands to always run locally; the enhancement in #22 was a suggestion to make a command run either remotely or locally depending on -how- the remote site alias was specified.

I just committed the one line fix to make site-set always run locally.

I added same line to site-alias and branched the current code as follows below. I ran out of time and brain power for this tonight. Not sure I will finish it. I'm having trouble finding the right conditions under which we should drush_invoke_process():

  $site_set = drush_sitealias_site_get();
  $alias = drush_get_context('DRUSH_TARGET_SITE_ALIAS');
  if ($alias && $site_set != $alias) {
    $options = drush_redispatch_get_options();
    $backend_options = array(
      'integrate' => FALSE,
    );
    $values = drush_invoke_process($alias, 'site-alias', func_get_args(), $options, $backend_options);
    return $values['object'];
  else {
    // All the code we run today

#27 looks about right to me in concept. I don't have time to run it to see if there are any actual operational problems with it; you imply that there is some trouble, but it looks like it must be pretty close to right to me.

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.