Example usage:

$ drush cli
Entering the drush cli.  Use CONTROL-D to exit.
Type 'help' for help.
drush> status
 PHP configuration     :  /etc/php5/cli/php.ini 
 Drush version         :  4.0-dev               
 Drush configuration   :  /home/ga/.drushrc.php 
drush> use @gkdev
drush @gkdev> status
 Drupal version         :  6.16                        
 Site URI               :  http://greenknowe.org       
 Database driver        :  pgsql                       
 Database hostname      :  localhost                   
 Database username      :  www-data                    
 Database name          :  greenknowedb                
 Database               :  Connected                   
 Drupal bootstrap       :  Successful                  
 Drupal user            :  Anonymous                   
 Default theme          :  green_zen                   
 Administration theme   :  garland                     
 PHP configuration      :  /etc/php5/cli/php.ini       
 Drush version          :  4.0-dev                     
 Drush configuration    :  /home/ga/.drushrc.php       
 Drupal root            :  /srv/www/dev.greenknowe.org 
 Site path              :  sites/greenknowe.org        
 File directory path    :  sites/greenknowe.org/files

Still proof-of-concept stage. Does not set prompt correctly when you first enter drush cli. Does not play nice with 'cd' ("use" takes precedence over current working directory; cd to a site dir should do an implied 'use').

CommentFileSizeAuthor
#13 cli-use-4.patch15.92 KBgreg.1.anderson
#11 cli-use-3.patch16.98 KBgreg.1.anderson
#5 cli-use-2.patch7.51 KBgreg.1.anderson
cli-use.patch911 bytesgreg.1.anderson

Comments

moshe weitzman’s picture

moshe weitzman commented

For brevity, I wonder if we should trim down the prompt from 'drush @gkdev' to just @gkdev. when you first start cli, it should probably either say '@self' or we work out the current site alias based on cwd ... i like your proposal that a cd imples a use. i have been mulling over the conflicts there and implied use resolves them perfectly from a user's point of view. i can see how this would be hard for you to code though. if it gets hard to determine the active site alias, maybe we use a long form for the prompt.

greg.1.anderson’s picture

greg.1.anderson commented

Yes, I was figuring if there was no alias then I would print /path/to/root#uri > for the prompt. Finding the alias from the long form is easy; I just need to enhance the sa command to output the name of the alias with a certain flag (--name?). Finding the long form from a 'cd' path is a simple matter of exporting the bootstrapping code. Maybe even just calling drush sa @self -name after a cd would be enough to figure out which site we bootstrap to (and make no change if the cwd does not indicate a site). This also applies to when cli is first entered; maybe the startup script just calls the cd function to set the prompt.

So it's all solvable, but as you said, it will take a little time to code up. 'use' was trivial, so I thought I'd post that as a sneak-preview. Also, I can get the 'drush' out of the prompt; that's a fine idea.

moshe weitzman’s picture

moshe weitzman commented

`drush sa @self -name` sounds good but I think we need to avoid the call to drush_bootstrap_max() in drush_sitealias_print(). Otherwise, we slow down cd too much.

greg.1.anderson’s picture

greg.1.anderson commented

Okay, I'll see what I can do to find the site by the same logic, but without doing a full bootstrap.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Needs work » Needs review
StatusFileSize
new cli-use-2.patch7.51 KB

I was wrong in #2; this was actually pretty easy to implement.

The prompt is "drush>" if there is no Drupal site, and @alias if there is some alias that identifies the current bootstrapped site. The cdd function has been renamed to cd, and fixed up so that it behaves as cd usually would when an alias is not used. cdd is aliased to cd for backwards compatibility. Any cd or cdd that uses a site alias or ends up inside the site folder of some Drupal site will cause an implicit 'use'. You can still explicitly 'use' an alias; for example, you can 'use @remotesite', and every command done thereafter will target the remote machine.

I didn't need "sa --name"; there was already "sa --short" that did the same thing. I modified sa to not do a bootstrap_max() when called with --short. To support the features above, I also enhanced drush_sitealias_get_record() to accept a path to a site folder as an acceptable alias to that site.

Fiddle around with this a bit and see what you think. It seems to work pretty well, and it's pretty simple.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work

Code looks terrific. I'd like some more feedback on this patch. Lets hear it, folks. Please do real world testing if possible. This all sounds rosy on paper :)

  1. I tried a dubious operation like `cd @hci` which is an alias to a remote host. in this case my prompt changed but my cwd did not. i expected to see an error message ... on further thought, it would be nifty to actually ssh me to the target site with an interactive terminal. i would leave cli mode but thats ok.
  2. `cd -` does not work in the shell. not a big deal
  3. I think it is OK as is, I did get a bit confused with the combination of use and cd. commands work against your 'used' site but cd works against your cwd. for example, `cd files` ignores the site in use and honors your cwd. hope this explanation makes sense.
  4. drush cli --help should be updated
  5. is it possible to source my personal .bashrc so that all those aliases and functions work inside the cli shell?
  6. I'd say that we could do with some inline comments in the generated bash code. Thats not urgent at all. I bet we have many people who aren't used to reading bash so comments help.
greg.1.anderson’s picture

greg.1.anderson commented

Back in town; here are my comments on your comments.

  1. At the moment, use @remotealias allows you to 'use' a remote machine remotely. cwd does not change, but every drush command thereafter is remote. Perhaps a 'cwd not changed' message would be appropriate for remote aliases. Note that currently, 'use' does not change cwd for local aliases either, but I think it should. ssh is another idea, but I think that perhaps there should be a different command to do that.
  2. Bug...
  3. Not sure how this should work. Seems that 'cd files' should first try @self:%files, and then look for ./files if the former is not found.
  4. Yep.
  5. Agree; there's probably a different flag than --bashrc that I could use.
  6. Also agreed.

Heading out of town for a couple of weeks in a week; will get back to this when I have a chance.

moshe weitzman’s picture

moshe weitzman commented

1. I think we can leave things as is for cd and use. That is, don't print a 'cwd not changed', don't do a cd during a local `use`.

perusio’s picture

perusio commented

I applied this patch against CVS head and it works. One snafu that hit me several times was just having a simple 'drush>' prompt and mistaking one site for the other. Now by issuing 'use @' I know exactly where I am.

But I'm wondering if this could be made to select an alias automagically. I mean something like this:
I'm in drupal site dir I enter the drush CLI. Automatically my prompt should reflect that fact.

If the site has an alias use the alias, if not use the site_name variable if set.

Just an idea. Thank you for all the work going into drush.

greg.1.anderson’s picture

greg.1.anderson commented
Component: Code » PM (dl, en, up ...)
Priority: Normal » Major

Somehow I had thought that this was committed prior to DrupalCon SF, but it was not. :p

Bumping this up; I'll try to get it in for drush-4 if I can.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Needs work » Needs review
StatusFileSize
new cli-use-3.patch16.98 KB

Here is a new patch that works pretty well and is self-consistent. There were some pretty nasty things going on in core-cli without this patch. The php-eval command alias 'eval' was overriding the bash builtin 'eval' command, which broke autocompletion and a whole bunch of other stuff. Now, bash builtin commands and regular shell commands (e.g. grep) take precedence over drush commands and aliases unless the 'cli-override' option is used to specify that the drush command has a higher priority. By default, 'help' and 'dd' are the drush command; bash builtins take precedence for everything else.

Another feature I added: drush core-cli --pipe will dump the generated .bashrc and exit. This makes it easy to copy all of the drush aliases and functions into your own .bashrc, pick-and-choose what you want to keep, and turn your default shell into a drush shell (if you want).

'cdd' is no longer necessary; 'cd' works as it should, and either will do an ordinary cd, or can be used to select a different Drupal site to use.

Regarding the things mentioned in #6:

  1. `cd @remotealais` is rejected. `use @remotealias` works. `use` and `cd` are about the same in terms of function, except that cd will change your working directory, and use will not.
  2. Fixed.
  3. Now more consistent. Now, cd is "just a cd" if the arg is empty or "-" or a path to a directory that exists. If it is not one of these things, then an attempt is made to interpret it as @alias or %modules or @alias:%modulename, etc. cd will not do an implicit 'use' unless your argument contains an alias.
  4. Done.
  5. Already done (I think you did it...)
  6. Done.

I'd like to see this patch to completion. core-cli is only nominally useful without 'use'; with it, I think it is starting to get pretty compelling.

moshe weitzman’s picture

moshe weitzman commented

The code looks good. Should '$options['cli-override'] use $command_specific?

Got a collision on my first bit of testing. 'sa' is apparently also a unix command for 'system accounting'. perhaps we should override it?

The code below is from core-cli help and seems not to work. Neither does %files instead of files.

@self> lsd files
Target 'files' not found.

cd without any value took me to my home dir. but i rather liked the old behavior where cdd without any further param took you to the root of the drupal site. perhaps we should take over cd if no param is passed.

when you try to cd into a remote alias, you get 'Could not find @slice.'. would be good to get a more descriptive error there. alternatively, i think it would be cool to actually perform an ssh and cd into drupal root (or site rot if feasible) when someone does this.

greg.1.anderson’s picture

greg.1.anderson commented
StatusFileSize
new cli-use-4.patch15.92 KB

Renamed cli-override to just override and put in a command-specific example for it.

Added sa to the list of default overrides.

Changed cd == cd %root. Standard bash cd ~ is still available to quickly go to your home directory.

The problem with lsd files and lsd %files is that you had no DRUPAL_SITE. You should never see the prompt "@self>"; that means "I'm at the site that I'm currently at right now...". When drush tries to evaluate that, it finds nothing. In this patch, drush now tries harder to find the right site alias, so you will probably see a better prompt, and files and %files should then work. If drush still cannot find an alias for the cwd, then the prompt with be ">", and you will at least know why files / %files is not working.

I forgot to commend on cd @live == ssh live. This feature may be a bit too convenient. Consider two sites, @live and @dev, on different machines:

@dev> cd @live
@live> ... do stuff
@live> cd @dev
@dev> ... do stuff
@dev> cd @live

In this sequence, the ssh sessions 'pile up' with more and more tunnels for the data to pass through. You can 'exit' your way out of the sessions, but if you exit one too far, then your terminal window closes. Your bash history also gets weird in this scenario. This might turn out to be just fine once you got used to it, but it seemed a bit complicated to tackle right now. Instead, I put in a better error message.

moshe weitzman’s picture

moshe weitzman commented

Now I am just seeing just a '>' at command prompt. Thats fine. cd %modules works, as does cd devel. Those are pretty slow though. Did we used to do those without a full bootstrap?

lsd %modules works but lsd %files does not. I get 'Target '%files' not found.'

We can punt for now on the ssh pileup issue. I'm thinking that we should not drop use back into core-cli and thus the user is not likely 'cd' again.

greg.1.anderson’s picture

greg.1.anderson commented

If your prompt is ">", then %modules will work if you are cd'ed to a directory that will cause Drush to select your site during a bootstrap. cd calls dd, which is bootstrap drush, but dd will call status, which is bootstrap max; however, status is only called if there is a % item in the path (and the alias is not remote). I'm not sure this could be optimised any further.

I'm not sure why %files is not working; if %modules is working, then so should %files.

Close enough to commit?

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Fixed

Fixed `dd %files` with http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands... ... My commit msg went awry there. Didn't mean to use real backticks.

I've committed this, and am about to release RC5.

I made a tiny optimization to drush_sitealias_evaluate_path() that I think is harmless: http://drupal.org/cvs?commit=469992

greg.1.anderson’s picture

greg.1.anderson commented

Your changes look good. Thanks for committing.

Status: Fixed » Closed (fixed)

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