The other day at work, I found myself needing to see a list of Subversion commits by a specific user. I spent a few minutes looking at the svn log help, but nothing seemed to be designed to show commits by user. It took me a while to find something to do the trick, but this is it:
svn log | sed -n '/username/,/-----$/ p'
Gotta love sed!
There comes a time in each of our individual lives that we just learn to love log files. We learn to love utilities like tail and grep as we pore over countless lines of information, seeking out the stuff that really matters. We like to show off our debugging prowess as innocent bystanders look on in absolute wonderment.
While that's all fine and dandy, I'm always on the lookout for utilities to make my log monitoring less painful. A few weeks ago, my supervisor introduced me to a program that he's been using for quite some time: multitail. In essence, it's tail with some really neat features, such as the ability to:
I've been using multitail for a couple of weeks now (it took me a while to warm up to it after my supervisor introduce it), and I'm quite satisfied with it. One thing I really, really like about multitail is that I can kinda sorta almost monitor multiple remote files. What does that mean, you ask?
Well, my development environment includes at least 5 virtual machines, each of which will be logging different but equally important information. I want to be able to "tail" a specific log file on each of the virtual machines in one window. Now, it took me a while to learn how to do this, which is why I'm sharing the information with you.
And here comes my usual disclaimer: this may not be the most efficient way to do what I want to do, but it's currently working for me. I'm open to other solutions too!
Anyway, I can run a command like the following to monitor multiple remote log files:
multitail -l 'ssh user@host1 "tail -f /path/to/log/file"' -l 'ssh user@host2 "tail -f /path/to/log/file"'
Such a command would ssh into two computers, host1 and host2, and run tail -f /path/to/log/file on each. Multitail allows you to monitor the output of both tail commands in a single window, reducing clutter on your desktop. You can also arrange the files/commands you're "tailing" into various rows and columns. I tend to have a 2x2 grid of log files when I use multitail at work.
I've also started using multitail to monitor the access and error logs for my Django sites on WebFaction. I simply ssh into my account, run an alias for a ridiculous multitail command, and watch as both log files scroll on by.
Again, this is just another aspect of my work environment that is fun and useful to me, and I wanted to spread the joy. Multitail may or may not be a utility you like to use, but it suits my current needs and desires quite well. YMMV. And, once again, I'm always on the look-out for other tools to make my work life more interesting and productive!
I often find myself taking notes about various aspects of my job that I feel I would forget as soon as I moved onto another project. I've gotten into the habit of taking my notes using reStructured Text, which shouldn't come as any surprise to any of my regular visitors. On several occasions, I had some of the other guys in the company ask me for some clarification on some things I had taken notes on. Lucky for me, I had taken some nice notes!
However, these individuals probably wouldn't appreciate reading ReST markup as much as I do, so I decided to do something nice for them. I setup Sphinx to prettify my documentation. I then wrote a small Web server using Python, so people within the company network could access the latest version of my notes without much hassle.
Just like I take notes to remind myself of stuff at work, I want to do that again for this automated ReST->HTML magic--I want to be able to do this in the future! I figured I would make my notes even more public this time, so you all can enjoy similar bliss.
Platform Dependence
I am writing this article with UNIX-like operating systems in mind. Please forgive me if you're a Windows user and some of this is not consistent with what you're seeing. Perhaps one day I'll try to set this sort of thing up on Windows.
The first step that we want to take is installing Sphinx. This is the project that Python itself uses to generate its online documentation. It's pretty dang awesome. Feel free to skip this section if you have already installed Sphinx.
Depending on your environment of choice, you may or may not have a package manager that offers python-sphinx or something along those lines. I personally prefer to install it using pip or easy_install:
$ sudo pip install sphinx
Running that command will likely respond with a bunch of output about downloading Sphinx and various dependencies. When I ran it in my sandbox VM, I saw it install the following packages:
It should be a pretty speedy installation.
We'll be using Mercurial to keep track of changes to our ReST documentation. Mercurial is a distributed version control system that is built using Python. It's wonderful! Just like with Sphinx, if you have already installed Mercurial, feel free to skip to the next section.
I personally prefer to install Mercurial using pip or easy_install--it's usually more up-to-date than what you would have in your package repositories. To do that, simply run a command such as the following:
$ sudo pip install mercurial
This will go out and download and install the latest stable Mercurial. You may need python-dev or something like that for your platform in order for that command to work. However, if you're on Windows, I highly recommend TortoiseHg. The installer for TortoiseHg will install a graphical Mercurial client along with the command line tools.
Now let's create a brand new Mercurial repository to house our notes/documentation. Open a terminal/console/command prompt to the location of your choice on your computer and execute the following commands:
$ hg init mydox $ cd mydox
The next step is to configure Sphinx for our project. Sphinx makes this very simple:
$ sphinx-quickstart
This is a wizard that will walk you through the configuration process for your project. It's pretty safe to accept the defaults, in my opinion. Here's the output of my wizard:
$ sphinx-quickstart Welcome to the Sphinx quickstart utility. Please enter values for the following settings (just press Enter to accept a default value, if one is given in brackets). Enter the root path for documentation. > Root path for the documentation [.]: You have two options for placing the build directory for Sphinx output. Either, you use a directory "_build" within the root path, or you separate "source" and "build" directories within the root path. > Separate source and build directories (y/N) [n]: y Inside the root directory, two more directories will be created; "_templates" for custom HTML templates and "_static" for custom stylesheets and other static files. You can enter another prefix (such as ".") to replace the underscore. > Name prefix for templates and static dir [_]: The project name will occur in several places in the built documentation. > Project name: My Dox > Author name(s): Josh VanderLinden Sphinx has the notion of a "version" and a "release" for the software. Each version can have multiple releases. For example, for Python the version is something like 2.5 or 3.0, while the release is something like 2.5.1 or 3.0a1. If you don't need this dual structure, just set both to the same value. > Project version: 0.0.1 > Project release [0.0.1]: The file name suffix for source files. Commonly, this is either ".txt" or ".rst". Only files with this suffix are considered documents. > Source file suffix [.rst]: One document is special in that it is considered the top node of the "contents tree", that is, it is the root of the hierarchical structure of the documents. Normally, this is "index", but if your "index" document is a custom template, you can also set this to another filename. > Name of your master document (without suffix) [index]: Please indicate if you want to use one of the following Sphinx extensions: > autodoc: automatically insert docstrings from modules (y/N) [n]: > doctest: automatically test code snippets in doctest blocks (y/N) [n]: > intersphinx: link between Sphinx documentation of different projects (y/N) [n]: > todo: write "todo" entries that can be shown or hidden on build (y/N) [n]: > coverage: checks for documentation coverage (y/N) [n]: > pngmath: include math, rendered as PNG images (y/N) [n]: > jsmath: include math, rendered in the browser by JSMath (y/N) [n]: > ifconfig: conditional inclusion of content based on config values (y/N) [n]: A Makefile and a Windows command file can be generated for you so that you only have to run e.g. `make html' instead of invoking sphinx-build directly. > Create Makefile? (Y/n) [y]: > Create Windows command file? (Y/n) [y]: n Finished: An initial directory structure has been created. You should now populate your master file ./source/index.rst and create other documentation source files. Use the Makefile to build the docs, like so: make builder where "builder" is one of the supported builders, e.g. html, latex or linkcheck.
If you followed the same steps I did (I separated the source and build directories), you should see three new files in your mydox repository:
We'll do our work in the source directory.
Now is the time when we start writing some ReST that we want to turn into HTML using Sphinx. Open some file, like first_doc.rst and put some ReST in it. If nothing comes to mind, or you're not familiar with ReST syntax, try the following:
========================= This Is My First Document ========================= Yes, this is my first document. It's lame. Deal with it.
Save the file (keep in mind that it should be within the source directory if you used the same settings I did). Now it's time to add it to the list of files that Mercurial will pay attention to. While we're at it, let's add the other files that were created by the Sphinx configuration wizard:
$ hg add adding ../Makefile adding conf.py adding first_doc.rst adding index.rst $ hg st A Makefile A source/conf.py A source/first_doc.py A source/index.rst
Don't worry that we don't see all of the directories in the output of hg st--Mercurial tracks files, not directories.
Here comes the magic in automating the conversion from ReST to HTML: Mercurial hooks. We will use the precommit hook to fire off a command that tells Sphinx to translate our ReST markup into HTML.
Edit your mydox/.hg/hgrc file. If the file does not yet exist, go ahead and create it. Add the following content to it:
[hooks] precommit.sphinxify = ~/bin/sphinxify_docs.sh
I've opted to call a Bash script instead of using an inline Python call. Now let's create the Bash script, ~/bin/sphinxify_docs.sh:
#!/bin/bash cd $HOME/mydox sphinx-build source/ docs/
Notice that I used the $HOME environment variable. This means that I created the mydox directory at /home/myusername/mydox. Adjust that line according to your setup. You'll probably also want to make that script executable:
$ chmod +x ~/bin/sphinxify_docs.sh
You should now be at a stage where you can safely commit changes to your repository and have Sphinx build your HTML documentation. Execute the following command somewhere under your mydox repository:
$ hg ci -m "Initial commit"
If your setup is anything like mine, you should see some output similar to this:
$ hg ci -m "Initial commit" Making output directory... Running Sphinx v0.6.4 No builder selected, using default: html loading pickled environment... not found building [html]: targets for 2 source files that are out of date updating environment: 2 added, 0 changed, 0 removed reading sources... [100%] index looking for now-outdated files... none found pickling environment... done checking consistency... /home/jvanderlinden/mydox/source/first_doc.rst:: WARNING: document isn't included in any toctree done preparing documents... done writing output... [100%] index writing additional files... genindex search copying static files... done dumping search index... done dumping object inventory... done build succeeded, 1 warning. $ hg st ? docs/.buildinfo ? docs/.doctrees/environment.pickle ? docs/.doctrees/first_doc.doctree ? docs/.doctrees/index.doctree ? docs/_sources/first_doc.txt ? docs/_sources/index.txt ? docs/_static/basic.css ? docs/_static/default.css ? docs/_static/doctools.js ? docs/_static/file.png ? docs/_static/jquery.js ? docs/_static/minus.png ? docs/_static/plus.png ? docs/_static/pygments.css ? docs/_static/searchtools.js ? docs/first_doc.html ? docs/genindex.html ? docs/index.html ? docs/objects.inv ? docs/search.html ? docs/searchindex.js
If you see something like that, you're in good shape. Go ahead and take a look at your new mydox/docs/index.html file in the Web browser of your choosing.
Not very exciting, is it? Notice how your first_doc.rst doesn't appear anywhere on that page? That's because we didn't tell Sphinx to put it there. Let's do that now.
Edit the mydox/source/index.rst file that was created during Sphinx configuration. In the section that starts with .. toctree::, let's tell Sphinx to include everything we ReST-ify:
.. toctree:: :maxdepth: 2 :glob: *
That should do it. Now, I don't know about you, but I don't really want to include the output HTML, images, CSS, JS, or anything in my documentation repository. It would just take up more space each time we change an .rst file. Let's tell Mercurial to not pay attention to the output HTML--it'll just be static and always up-to-date on our filesystem.
Create a new file called mydox/.hgignore. In this file, put the following content:
syntax: glob docs/
Save the file, and you should now see something like the following when running hg st:
$ hg st M source/index.rst ? .hgignore
Let's include the .hgignore file in the list of files that Mercurial will track:
$ hg add .hgignore $ hg st M source/index.rst A .hgignore
Finally, let's commit one more time:
$ hg ci -m "Updating the index to include our .rst files" Running Sphinx v0.6.4 No builder selected, using default: html loading pickled environment... done building [html]: targets for 1 source files that are out of date updating environment: 0 added, 1 changed, 0 removed reading sources... [100%] index looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... done writing output... [100%] index writing additional files... genindex search copying static files... done dumping search index... done dumping object inventory... done build succeeded.
Tada!! The first_doc.rst should now appear on the index page.
Who seriously wants to have HTML files that are hard to get to? How can we make it easier to access those HTML files? Perhaps we can create a simple static file Web server? That might sound difficult, but it's really not--not when you have access to Python!
#!/usr/bin/env python # -*- coding: utf-8 -*- from BaseHTTPServer import HTTPServer from SimpleHTTPServer import SimpleHTTPRequestHandler def main(): try: server = HTTPServer(('', 80), SimpleHTTPRequestHandler) server.serve_forever() except KeyboardInterrupt: server.socket.close() if __name__ == '__main__': main()
I created this simple script and put it in my ~/bin/ directory, also making it executable. Once that's done, you can navigate to your mydox/docs/ directory and run the script. Since I called the script webserver.py, I just do this:
$ cd ~/mydox/docs $ sudo webserver.py
This makes it possible for you to visit http://localhost/ on your own computer, or to use your computer's IP in place of localhost to access your documentation from a different computer on your network. Pretty slick, if you ask me.
I suppose there's more I could add, but that's all I have time for tonight. Enjoy!
One of the tools I find myself using more and more each day is the amazing grep. It helps me narrow down the list of potential problem children in my code. Sometimes it can even tell me exactly where I need to look if my parameters are specific enough.
For example, the other day, I had a problem where some Python code was attempting to call isdigit() on an integer, when the variable was supposed to be a string. I could have scoured the code manually for all occurrences of the word "isdigit", or I could have used a "search in files" sort of feature in any useful text editor. There are likely other options too. However, I opted to use grep to find what I was looking for.
In the process of fixing this bug, I learned that grep offers the option of displaying a few lines of context around your matching text. There are a few ways you can tell grep to give you some context:
-A NUM, --after-context=NUM
Print NUM lines of trailing context after matching lines. Places a line containing -- between contiguous groups of matches.
-B NUM, --before-context=NUM
Print NUM lines of leading context before matching lines. Places a line containing -- between contiguous groups of matches.
-C NUM, --context=NUM
Print NUM lines of output context. Places a line containing -- between contiguous groups of matches.
I thought this was so useful that I wrote a small shell script to wrap up my common options for grepping--recursive search, display line numbers, and (now) showing some context. Eventually I got around to cleaning up the output by dirtying up the script. Cleaning up the output involved only displaying a matching filename one time, with the line numbers for the context and matching lines below it. I also thought it would be easier to find matching lines if I could colorize the matched text. Here's my script as of noon today.
#!/bin/bash # Recursively greps for some text in files in the current directory with some # context lines. GREEN=`echo -e '\033[41;30;1m'` NORMAL=`echo -e '\033[0m'` FIND=$1 grep --exclude=*.svn* --exclude=*.swp -rnC 5 "$FIND" * | \ awk '{split($1, a, "-"); split(a[1], b, ":"); \ if (b[1] != file) { file=b[1]; print file; } \ sub(file, "", $0); print $0; }' | \ sed -e "s/$FIND/$GREEN&$NORMAL/g;s/^[-\:]//g"
I'm sure there are ways to make this more elegant, but I'm sure happy with it. This little dandy assisted me just this morning in helping a friend resolve some Django bugs!
Here's a screenshot:
Every so often I find myself in need of a small ego boost (or reality check). One of the things I've done in the past to satisfy such a need is go to the PyPI and see how many downloads my packages have. Depending on how much time I have or how much effort I want to put into my pride, I may or may not check the download stats for all releases of each package.
A couple of weeks ago, I was in the mood for an ego boost. It was actually an every day thing for nearly a week! So, instead of wasting a lot of time checking download stats for each version of each package I have on PyPI, I wrote a script to do it for me. It uses the XML-RPC API that PyPI offers.
Here she is!
#!/usr/bin/env python # -*- coding: utf-8 -*- """ Calculates the total number of downloads that a particular PyPI package has received across all versions tracked by PyPI """ from datetime import datetime import locale import sys import xmlrpclib locale.setlocale(locale.LC_ALL, '') class PyPIDownloadAggregator(object): def __init__(self, package_name, include_hidden=True): self.package_name = package_name self.include_hidden = include_hidden self.proxy = xmlrpclib.Server('http://pypi.python.org/pypi') self._downloads = {} self.first_upload = None self.first_upload_rel = None self.last_upload = None self.last_upload_rel = None @property def releases(self): """Retrieves the release number for each uploaded release""" result = self.proxy.package_releases(self.package_name, self.include_hidden) if len(result) == 0: # no matching package--search for possibles, and limit to 15 results results = self.proxy.search({ 'name': self.package_name, 'description': self.package_name }, 'or')[:15] # make sure we only get unique package names matches = [] for match in results: name = match['name'] if name not in matches: matches.append(name) # if only one package was found, return it if len(matches) == 1: self.package_name = matches[0] return self.releases error = """No such package found: %s Possible matches include: %s """ % (self.package_name, '\n'.join('\t- %s' % n for n in matches)) sys.exit(error) return result @property def downloads(self, force=False): """Calculate the total number of downloads for the package""" if len(self._downloads) == 0 or force: for release in self.releases: urls = self.proxy.release_urls(self.package_name, release) self._downloads[release] = 0 for url in urls: # upload times uptime = datetime.strptime(url['upload_time'].value, "%Y%m%dT%H:%M:%S") if self.first_upload is None or uptime < self.first_upload: self.first_upload = uptime self.first_upload_rel = release if self.last_upload is None or uptime > self.last_upload: self.last_upload = uptime self.last_upload_rel = release self._downloads[release] += url['downloads'] return self._downloads def total(self): return sum(self.downloads.values()) def average(self): return self.total() / len(self.downloads) def max(self): return max(self.downloads.values()) def min(self): return min(self.downloads.values()) def stats(self): """Prints a nicely formatted list of statistics about the package""" self.downloads # explicitly call, so we have first/last upload data fmt = locale.nl_langinfo(locale.D_T_FMT) sep = lambda s: locale.format('%d', s, 3) val = lambda dt: dt and dt.strftime(fmt) or '--' params = ( self.package_name, val(self.first_upload), self.first_upload_rel, val(self.last_upload), self.last_upload_rel, sep(len(self.releases)), sep(self.max()), sep(self.min()), sep(self.average()), sep(self.total()), ) print """PyPI Package statistics for: %s First Upload: %40s (%s) Last Upload: %40s (%s) Number of releases: %34s Most downloads: %35s Fewest downloads: %35s Average downloads: %35s Total downloads: %35s """ % params def main(): if len(sys.argv) < 2: sys.exit('Please specify at least one package name') for pkg in sys.argv[1:]: PyPIDownloadAggregator(pkg).stats() if __name__ == '__main__': main()
Usage is pretty simple. All you need to do is call the script (I called it pypi_downloads.py with the name or names of the package(s) you want download stats for:
bash-4.0$ ./pypi_downloads.py clip2zeus
PyPI Package statistics for: Clip2Zeus
First Upload: Sun 10 Jan 2010 03:25:30 AM (0.1)
Last Upload: Mon 18 Jan 2010 06:58:42 PM (0.9d)
Number of releases: 12
Most downloads: 41
Fewest downloads: 21
Average downloads: 28
Total downloads: 342
And there you have it!
I just learned yet another goodie about the Bash shell that I must share with you. This trick made my day on so many levels.
You know how annoying it is when you get those ridiculously long commands in a terminal window? You know how much more annoying it is when you generally can't Ctrl+arrow around the command to change bits and pieces when you're on OSX? If you've ever been in that boat, this tip is for you.
Bash allows you to hit Ctrl+x Ctrl+e to edit your current command in your "preferred" editor. Your "preferred" editor is determined from the EDITOR environment variable. Since I'm a fan of VIM, all I need to do is make sure I've got export EDITOR=vim in my .bashrc or something along those lines. Once I do that, I can hit Ctrl+x Ctrl+e anytime I am using Bash and have a smelly, long command I want to manipulate.
With all of the exciting updates to Mercurial recently, I've been on a rampage, updating various boxes everywhere I go. I'm in the habit of using easy_install and/or pip to install most of my Python-related packages. It's pretty easy to install packages that are in well-known locations (like PyPI or on Google Code, for example). It's also pretty easy to update packages using either utility. Both take a -U parameter, which, to my knowledge, tells it to actually check for updates and install the latest version.
That's all fine and dandy, but what happens when you want to install an "unofficial" version of some package? I mean, what if your favorite project all of the sudden includes some feature that you will die unless you can have access to it and the next official version is weeks or months in the future? There are typically a few avenues you can take to satisfy your needs, but I wanted to bring up something that I think not many people are aware of: easy_install and pip can both understand URLs to installable Python packages.
What do I mean by that, you ask? Well, when you get down to the basics of what both utilities do, they just take care of downloading some Python package and installing it with the setup.py file contained therein. In many cases, these utilities will search various package repositories, such as PyPI, to download whatever package you specify. If the package is found, it will be downloaded and extracted.
In most cases, you can do all of that yourself:
$ wget http://pypi.python.org/someproject/somepackage.tar.gz $ tar zxf somepackage.tar.gz $ cd somepackage $ python setup.py install
Both easy_install and pip obviously do a lot of other magic, but that is perhaps the most basic way to understand what they do. To answer that last question, you can help your utility of choice out by specifying the exact URL to the specific package you want it to install for you:
$ easy_install http://pypi.python.org/someproject/somepackage.tar.gz $ pip install http://pypi.python.org/someproject/somepackage.tar.gz
For me, this feature comes in very handy with projects that are hosted on BitBucket, for example, because you can always get any revision of the project in a tidy .tar.gz file. So when I'm updating Mercurial installations, I can do this to get the latest stable revision:
$ easy_install http://selenic.com/repo/hg-stable/archive/tip.tar.gz
It's pretty slick. Here's a full example:
[user@web ~]$ hg version Mercurial Distributed SCM (version 1.2.1) Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [user@web ~]$ easy_install http://selenic.com/repo/hg-stable/archive/tip.tar.gz Downloading http://selenic.com/repo/hg-stable/archive/tip.tar.gz Processing tip.tar.gz Running Mercurial-stable-branch--8bce1e0d2801/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Gnk2c9/Mercurial-stable-branch--8bce1e0d2801/egg-dist-tmp--2VAce zip_safe flag not set; analyzing archive contents... mercurial.help: module references __file__ mercurial.templater: module references __file__ mercurial.extensions: module references __file__ mercurial.i18n: module references __file__ mercurial.lsprof: module references __file__ Removing mercurial unknown from easy-install.pth file Adding mercurial 1.4.1-4-8bce1e0d2801 to easy-install.pth file Installing hg script to /home/user/bin Installed /home/user/lib/python2.5/mercurial-1.4.1_4_8bce1e0d2801-py2.5-linux-i686.egg Processing dependencies for mercurial==1.4.1-4-8bce1e0d2801 Finished processing dependencies for mercurial==1.4.1-4-8bce1e0d2801 [user@web ~]$ hg version Mercurial Distributed SCM (version 1.4.1+4-8bce1e0d2801) Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Notice the version change from 1.2.1 to 1.4.1+4-8bce1e0d2801. w00t.
Edit: devov pointed out that pip is capable of installing packages directly from its repository. I've never used this functionality, but I'm interested in trying it out sometime! Thanks devov!
I just noticed that Mercurial 1.4.1 was released today. Most of the changes are pretty minor, but I wanted to voice my appreciation for a new extension that is included with this release: schemes.
This extension basically makes your life easier by shortening redundant URLs for you. For example, you can now use the following command to snag my simple Mercurial extensions repo from BitBucket:
hg clone bb://codekoala/hgext
Without hgext.schemes, that command would be something like one of the following commands:
hg clone http://bitbucket.org/codekoala/hgext hg clone ssh://hg@bitbucket.org/codekoala/hgext
Not the most ground-breaking of extensions, but still pretty slick!
The other day I was helping a friend get their Django site back online, and I found myself doing a couple of very similar commands when backing up the databases:
$ pg_dump -U some_database -f some_database_backup.sql
I use Bash as my shell in Linux, and apparently it's capable of doing some neat string substitution. I wanted to try something I had seen a few days prior to save myself a few keystrokes. Here's what I was trying to do:
$ pg_dump -U some_database -f some_database_backup.sql $ ^some_database^some_other_database
Which, I had hoped would replace all instances of some_database with some_other_database from the previously executed command. It turns out that the ^search-for^replace-with is only good for one substitution. That means that my sneaky attempt at saving keystrokes just overwrote the first database's backup with the backup of the second database. In other words, I was getting this:
$ pg_dump -U some_database -f some_database_backup.sql $ pg_dump -U some_other_database -f some_database_backup.sql
...when I wanted this...
$ pg_dump -U some_database -f some_database_backup.sql $ pg_dump -U some_other_database -f some_other_database_backup.sql
I did a little more digging today, and it turns out that I should have been using the following syntax:
$ pg_dump -U some_database -f some_database_backup.sql $ !!:gs/some_database/some_other_database/
The !! is shorthand for executing the previous command, and the :gs is used for global string replacement. And there you have it!
Out of curiosity, does anyone know of similar functionality in other shells?
Today I found myself trying to figure out how to make a terminal window stay permanent on my desktop or dashboard on OSX, similar to what I've done in the past with Linux. I just wanted to have the terminal window monitoring things in the background for me. Actually, all I wanted to do was keep track of when my local working copy of our Subversion repository was out of sync. I wanted a solution that would keep out of my way, but I also wanted it to be easy.
My search for a solution seemed short-lived when a Google search suggested a dashboard widget for the Terminal application. The problem with it was that the download server was dead or simply blocked by my company's Internet filter. One way or another, it wasn't long before I went in search of another solution.
At that very instant, I received a Growl notification from some program. That's when it dawned on me--I could tell Growl to tell me when my working copy was out of sync. I had done stuff like that in the past, so I set out to write my solution. This is what I came up with:
#!/bin/bash MY_BOX=[my IP address] DEV_ROOT='/path/to/svn/working copy' cd $DEV_ROOT MY_REV=`svn log --limit 1 | awk '/^r/ {print $1}' | sed 's/[^0-9]//g'` SVN_REV=`svn log --limit 1 -r HEAD | awk '/^r/ {print $1}' | sed 's/[^0-9]//g'` if [[ $MY_REV != $SVN_REV ]]; then ssh username@$MY_BOX "growlnotify -s -d47111 -n 'iTerm' -t 'Out Of Sync' -m 'Your working copy is out of sync. Repository is at revision $SVN_REV, and your working copy is at $MY_REV.'" fi
Now, a little bit about my environment. As I've mentioned before, all of our development really takes place on Linux-powered virtual machines. We simply use our Macs as the system to interact with those virtual machines. That is why there's the ssh line in that script.
Basically, this script just checks the most recent revision in your local working copy. Then it checks the latest revision in the repository itself. It compares the two revision numbers, and if it finds a difference, it will SSH into my OSX box to send me a Growl notification. On the OSX side, I have Growl and growlnotify installed. Here's a summary of the options to growlnotify:
This is a fabulous little reminder to me. I have it set up as a cronjob that runs every minute on my Linux-powered development virtual machine. Hopefully this will help others!