Skip to content
A simple bash shell script to create and work on local web sites.
Shell
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
README.md
localsite.sh

README.md

Localsite.sh - Create and load local web sites for development.

Hacked together by Joost Schuur (@jschuur).
Available from http://github.com/jschuur/localsite

Last updated 2010-09-23

Introduction

This simple bash script will set up a new development instance of a web site on your local machine by creating a new document root folder, adding DNS and configuring/restarting the web server.

Optionally, it will create local or remote git repos, launch the newly created URL in your browser or open the docroot in your text editor.

It assumes that your local development environment is already fully configured, and is designed for Mac OS X with nginx and Textmate in mind, but can be easily modified to accommodate alternate config settings. Look for the defaults block at the beginning of the script and the web server config text after the middle.

Out of the box, a few variables for directories, file locations and git identifiers need to be set up. See the Setup section of this readme for details.

Examples

Create a new site at http://larry.local:

localsite.sh larry

Create a new Rails 3 site at http://moe.local and load it up in your browser and editor

localsite.sh -t rails3 -o -e moe

Create a new site at http://curly.local and initialize it with a git repo

loadsite.sh -i http://github.com/moomerman/sinitter.git sinitter

Load existing site at http://shemp.local in both your browser and editor:

localsite.sh -l shemp

TIP: Create aliases with your preferred options:

alias losn='localsite.sh -o -e -g -r'
alias losw='localsite.sh -l'
alias losc='localsite.sh -c'

Then simply use losn newsite to create a new site or losw oldsite to work on an old one and load it up in your editor and browser. losc lets you tweak your site config if needed.

Usage

The last option passed to the script is considered to be site name 'slug' used in both the directory name and URL. By default, the site will live at http://slug.local and the document root will be in /Data/Sites/slug.local if you haven't modified the script.

Beyond that, the following command line options are available, all to be specified before the slug:

-c open site config file in editor 
-d list defaults
-e launch editor when done
-f open Finder to new site root dir
-g create local git repo
-h this help
-i intialize with specified git repo

-k create Heroku site too -l just load the site in the editor and browser, skip creation -o open new URL in current browser -q quite mode (error still generate output) -r create remote git repo -t add additional stub files (e.g. '-t sinatra' or '-t rails3') -u use existing dir and continue setup -v output version info

Setup

If you don't want to modify the script directly, a ~/.localsiterc will be loaded if present that can override the defaults set by the script. At the very least, you'll want to define SITES_DIR and SITES_CONF with the top level directory for all of your local site roots, as well as the web server config file that defines what sites are served up.

Git users will want to customize REMOTE_GIT_CMD / REMOTE_GIT_URL too.

The following example config file sets all four:

# System defaults
SITES_CONF='/opt/local/nginx/conf/sites.conf'
SITES_DIR='/Data/Sites'

# Site specific defaults
REMOTE_GIT_CMD="ssh joostschuur@git.joostschuur.com git init --bare /home/joostschuur/git/$SITE_NAME.git"
REMOTE_GIT_URL="ssh://joostschuur@git.joostschuur.com/~/git/$SITE_NAME.git"

Next, take a look at the site specific web server entry appended to your SITES_CONF file. By default, it's designed for my specific nginx configuration, but the format is easily modifiable.

Finally, you can customize any additional setup by creating a 'stub' function that will be used by the -t option. for -t rails, call it stub_rails, and run whatever commands are appropriate for your preferred Ruby on Rails setup. Stub setup is performed after the site root folder is created and git actions are performed, but before the web server configuration is updated. Thus by defining DOCUMENT_ROOT in your stub function, you can influence the root directory used in the config block, e.g. if you want to define a public subdirectory as the root.

You can even define new template stubs in this config file. Just create a function that starts with 'stub_' and the rest of the name will be the stub name you pass to the -t parameter. Here's a basic skeleton, that you'd later invoke with '-t custom':

function stub_custom {
    # Set this is you don't want the SITE_ROOT used for your web server config
    # and a 'public folder' doesn't exist in SITE_ROOT 
    DOCUMENT_ROOT="$SITE_ROOT/htdocs"

    # QUIET_MODE honors the -q flag. Redirect output of other commands to /dev/null if preferred.
    [ $QUIET_MODE ] || echo -n "Setting up custom app... "
    some_custom_generator_or_commands > /dev/null
    [ $QUIET_MODE ] || echo "Done!"
}

Release History

  • 0.5.4 - 9/23/10

    • -t stubs for rails3 and rails2 (rails just defaults to rails3)
  • 0.5.3 - 9/19/10

    • -t stubs for rails3 and rails2 (rails just defaults to rails3)
  • 0.5.2 - 9/17/10

    • -v gives version number
  • 0.5 - 9/12/10

    • ~/.localsiterc override
    • quite mode
    • stub creation with -t
    • -i to init with git repo
    • -f opens dir in Finder
  • Untagged - 9/6/10

    • Initial release
Something went wrong with that request. Please try again.