Cloud Platform
10 Command Line Tips
If there's anyone who has command of the command line, it's Dave Myburgh, a senior engineer at Acquia.
Dave has worked with Drupal for 10 years. His very first site went live on Drupal 4.7 the project started in Drupal 4.6 and it's still running. He's behind some big projects at Acquia. Day-to-day, Dave runs a team that handles the main Acquia.com website and several others, including this one, the Acquia Developer Center. Recently, he helped in the migration of the docs.acquia.com site from Drupal 6 to Drupal 8.
Dave has worked with just about every type of command line: from DOS, where he started, to Terminal, which he uses today. So we asked him to share how he works with the CLI -- to help us all improve the way we work. Here are the top ten command line tips that Dave suggested. Check them out, and increase your speed of development.
This depends on what system you use, but on the Mac, the default prompt usually offers your user name and a little $ sign. I find it rather boring and not very useful. It's something you're going to be looking at a lot, so if you want to quicken development and not get bored along the way, you might as well make it look pretty and be more functional.
1. I use Git for version control, and I find that the git-completion script is a great auto-complete option. Just type git, space, then start typing the word check and hit the TAB key. It will complete your entry to the word checkout and automatically add a space afterwards, and you can now start typing i (for the integration branch). Then hit TAB again and as long as that's the only branch that has the letter i at the beginning, it will autocomplete to integration.
This saves you from typing a fair amount of stuff, so you can type your command in about a second instead of about four or five seconds. If you're using that shortcut a lot in a day, you've gained a lot of time.
2. The git-prompt script allows you to change the way your prompt looks, and helps when you're in a Git repository on your command line. It will show you what branch you're in and whether or not that branch has been modified, both extremely useful perspectives.
To load both of those scripts, I saved them into my home folder, and in .bash_profile, I call them using source [filename]. Then I redefine the prompt, using export PS1 and whatever options I want to put in there.
3. It's sometimes nice to know how long a command took to run, so I include the current time in my prompt. So when I run something, I see the time when I typed the command, and when it completes. Now I can see just how long a database backup will take the next time I want to run it. It's a little thing, but in the big picture helps you budget your time a bit better.
4. And on that notion of saving time, .bash_profile is the script that runs every time I open Terminal. In Linux, it's .bashrc. It's is useful for setting up things that I want available all the time. The most important thing that I have in my bash_profile loads my Git enhancement scripts and sets up aliases. You can do the same.
5. For the most part, aliases are going to be shortcuts to existing commands. It makes typing things a lot faster. For example, I like to see a full directory listing with the file size, date, and attributes of the file, all that kind of stuff. The command to show all that is ls al. Using an alias I just shorten it to l. So now all I have to do is type l, hit the ENTER key, and the alias runs ls -al and I get my full directory listing. Your options for creating aliases are pretty much endless.
6. To prevent my .bash_profile file from getting too clogged with aliases, I've created a separate file called .aliases and put all the aliases in there. It also makes it easier to find stuff. In .bash_profile I simply reference the aliases file using source ~/.aliases. I can also run that same command source ~/.aliases manually every time I add a new alias to my list, because when you edit the file and add a new alias, nothing happens until you actually reload the aliases file. If, however, you close and re-open the terminal, any new aliases will automatically load.
7. Drush is a Drupal command line shell and scripting interface. It has useful commands to help manage your Drupal website, and other modules can add new functions and new commands to Drush. For example, the backup and migrate module: Not everyone is going to run it, but when you do have it installed, you're going to have commands to backup and restore the database without having to go through the Drupal admin pages.
It's really the most useful command line utility for Drupal. It's a huge increase in speed for development. You don't have to go clicking through your website many times waiting for pages to load. The most common thing I use Drush for is to clear caches. When you're doing development, you need to clear caches a fair number of times, especially now with Drupal 8 caching on by default - it's something you tend to forget to turn off on the development server.
8. Drush also helps with site aliases. To see all the site aliases that you have available, you can use drush sa. Site alias is a shortcut to a particular site on another server. Say I'm working on a local machine and I want to clear the caches on the Acquia.com production site. On my setup, I can just type in drush@ acquia.prod cc all. What drush does is login through ssh, go to the site folder, clear the caches and come back out. That saves you a whole bunch of time.
9. Nano and Vi (or Vim) are the two main command line editors most people will use. I like Nano because it has more or less similar commands to the old DOS editors from Windows. Most of your commands are done using CONTROL keys (even on the Mac). In Vi, you're always going to have to type in the colon and then the command and you also don't actually see a list of the commands without typing something. Nano, by contrast, shows a list of most commonly used commands on the bottom of the screen. For me, the old PC DOS element makes it easier (Norton Commander for DOS anyone?). I still like that kind of interaction.
10. One last thing: With Nano you don't see the line numbers by default. So if somebody is saying, "Oh, there's a bug in the code at this line number," and you want to have a quick look, it's hard to figure out what line number you're on. You can type in nano-c [filename] to have line numbers appear, but half the time, you forget to do that and then you exit the file and type it in again. If you create a .nanorc file in your home folder, and you just add the line set const, by default it will turn on line numbers for you so that whenever you just type nano [filename], line numbers are going to be on automatically, and you can see exactly where you are in the code. So much easier that way.
These suggestions are only the tip of the iceberg, but I hope they will let your work on the command line be quicker and more efficient. I won't command you to follow them, but please try some of them and see for yourself.
Cloud Platform