Ich habe drush unter /usr/local/share installiert und ein paar Shell-Aliase definiert:

alias drush=/usr/local/share/drush/drush

alias bdrush='drush -r ~/html/d6/ -l http://beispiel.de'

alias edrush='drush -r ~/html/d6/ -l http://example.org'

alias ddrush='drush -r ~/html/d6/ -l http://demo.example.org'

alias pdrush='drush -r ~/html/d6/ -l http://projects.example.org'

Drupal ist im Verzeichnis ~/html/d6/ installiert. Die Parameter -r und -l helfen drush, die gwünschte Website zu finden.

Und dann ist die Installation eines Modules so einfach wie:

drush dl support       # herunterladen nach sites/all/modules/

drush enable support   # Aktivieren des Moduls

Das Update einer Website wird mit

drush update

erledigt. Und an das Datenbankprompt bringt mich

drush sql cli

Den Rest findet Ihr selbst heraus. ;)

Nun wollte ich auf einfach Weise den Cron-Lauf für alle Websites zentralisieren. Und habe mir mit einem knappen Mehrzeiler geholfen:

#!/bin/bash

#

# Script to run the cron task on all installed Drupal sites.

#

# (C) 2009 Dirk Ruediger <dirk@niebegeg.net>

#

# This script depends on an Drupal installation, shell access to the

# server and drush installed.

#

;

# Where is the drush script located on my disk

#

DRUSH=/usr/local/bin/drush

;

# Any custom options for drush

#

OPTS=

;

# A listing of installation directories for drupal sites.

# On a confixx managed host Drupal is installed in an html/ subfolder in

# the client's home folder. The home folders are in /var/www.

#

ROOTS='/var/www/web*/html'

;

for s in $(find $ROOTS -name settings.php)

do

  DIR=$(echo $s | sed 's@/sites/.*@@')

  SITE=$(echo $s | sed 's@.*/sites/([^/]*)/.*@1@')

  if [ $SITE == 'default' ]

  then

      $DRUSH $OPTS  -r $DIR cron

  else

      $DRUSH $OPTS -r $DIR -l http://$SITE cron

  fi

done

Das Skript such in allen htdocs/-Verzeichnissen aller User eines onfixx-Hosts nach Drupal-Installationen und führt drush cron für alle Websites einer Installation aus. So macht Administration Spaß!

—

¹ Wer ist nicht genervt, wenn im Drei-Tage-Takt irgend ein Modul bei irgendeiner Installation eine Sicherheitsaktualisierung benötigt, man das tar.gz-Paket herunterlädt, auspackt, das FTP-Programm anwirft und die Dateien auf den Webserver zu laden und anschließend noch update.php auszuführen. Und immer in kleinen Chargen, um dem White screen of death wegen eines zu knapp bemessenen _memory_limit_ auszuweichen…

Aber 5 Minuten Tennis (zwei Runden, zweimal verloren) und 10 Minuten Boxen (2 Kämpfe, jeweils K.O.in der zweiten Runde) haben mich meine Meinung komplett korrigieren lassen. Boxen hat (mir) noch nie so viel Spaß gemacht. Und ich habe heute ‘nen klitzekleinen Muskelkater — zum Glück war es eben keine Spieleabend ;)

Nun gibt es immer wieder Programme (wie sqlplus oder cpan), die das nicht unterstützen, weil sie z.B. nicht gegen libreadline gebaut sind. Das sieht dann so aus – hier ein Beispiel mit der Oracle DB console:

pre. # sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 – Production on Fri Feb 29 21:30:17 2008
Copyright© 1982, 2005, Oracle.  All rights reserved.
SQL> ^[[A[[B

Man beachte die letzte Zeile. Dort wollte ich ein vorheriges Kommando nochmal ausführen.

Aber da gibts eine Lösung: rlwrap. Es übernimmt das eigentlich auszuführende Kommando mit all seinen Argumenten als Argument, filtert die Eingaben und schreibt sie mit.

pre. # rlwrap sqlplus /nolog

Wenn man dann mit den Cursortasten blättern will, kramt rlwrap in seiner Historie und übergibt erst nach (ggf. Modifikation) und Eingabe von Enter die komplette Kommandozeile an das eigentliche Programm.
Für seine Historie hält sich rlwrap für jeden verwalteten Befehl eine Historydatei im $HOME des Benutzers:

pre. # ls -la .*_history
rw——— 1 oracle oinstall 77 1. Mar 10:56 .sqlplus_history
rw——— 1 oracle oinstall 4539 1. Mar 10:56 .bash_history

Klasse!