I recently added the script drupalUpdate.sh to my Drupal Script Library. This script will update a site completely from the command line. It calls drupalCVSDeploy.sh to update the site then calls the drush update command to update the database.
Today I renamed the drupalManageFCKEditor.sh script to drupalManageLibraries.sh.
drupalManageFCKEditor.sh was a script I had written to help with the installation and maintenance of the FCKEditor library that is required to make the Drupal fckeditor module work. It allowed downloading the latest version of the file and looking inside the installed directory for modifications to the original files.
UPDATE: See comments below for update to this post.
While I do think the administration services offered by my Drupal Scripts Library are generally better than those offered by drush for administering collections of Drupal websites; I acknowledge that drush has its usefulness. Drush has a flexible plug-in architecture and there are lots of extensions contributed by the Drupal community. Also, drush is written in PHP which allows it to leverage functionality from within the Drupal installation itself. In said environment, there is no need to use drush to install and update code; but there is other functionality that can be leveraged.
Installing drush is fairly straight-forward. It is packaged as a Drupal module and available in Drupal's contrib CVS space. The easiest way to download it is to use the drupalCVSDeploy.sh script:
drupalCVSDeploy.sh -versiontag HEAD install module drush <site name>
Here I'll discuss the setup of a pair of Drupal websites, one a development ('dev') site and one a production ('prod'), and a system allowing the migration of state between them (promotion). This discussion, and the procedures described assume the presence of my Drupal Script Library.
In many cases, especially those of high-visibility, high-importance sites, it is desirable to see how changes will affect a site before releasing the change to the public. A new module, new content, or even updates need to be tested in a development environment before being effected on the production site.
Having a development environment on which changes can be staged allows assurance that a change doesn't have any negative effects as well as giving stake-holders an opportunity to sign off on the change before it goes live.
UPDATE: ShellEd version 2.0 has a new installation procedure:
I just tried this and it worked fine against Eclipse Helios
I've been having getting my normal editor working (a Winders editor that I run under wine) and thought I'd give eclipse a shot.
I did some searching and ended up installing the ShellEd plugin. It offers source coloring and context sensitive help popups. It doesn't create a custom perspective or a project type; but that's fine. I'd be happer with the solution if eclipse offered text wrapping (!). Despite that, the system seems to work fairly well.
Today, for a site I maintain, I did some work on how anonymous comment posts work. The goal was to support anonymous commentst that would be published and to send an admin a notification email. In addition to this, I did some setup so that anon comment posting would work w/ the the 'Filtered HTML' input format even tho 'Full HTML' was the sitewide default to support the use of the FCKEditor. This was all done w/ contrib modules and configuration.
Going thru the optional packages in Fedora is always a pain, but after the required 30 minutes or so, I finished. I reboot the machine and it came right up in Fedora, no problems. I connected it to my local wifi network, installed the fastestmirror package, then began the 200M+ update.
I just got a new (to me) laptop -- my brother's old hand-me-down Dell Latitude D630. (He went to the dark side and started using a proprietary operating system.) I'm currently in the process of wiping off the XP install and installing Fedora 11 (12 doesn't come out for another month). One of the first steps in any install is to choose a name for the new machine. (For a fun aside be sure to see the now-crufty RFC1178 :^)
A long time ago, I settled on the naming convention of using Latin (Hispanic) mens' names for my machines. At this point, I have no idea why I decided this... As I was coming up w/ the name for my new machine, I thought I'd catalog all the machine names I've used in the past. This list is presented in reverse chronological order starting w/ the new name for my new machine.
I just helped to found a Drupal development company: Chicago Drupal Authority
Go check 'em out.