monkey!

October 9, 2008

Xclip - Using the clipboard from the command line

Today I was setting up an account on Github and I needed to supply them with my ssh public key. The recommended method was to use something like pbcopy, which is on Mac OS X to copy the contents of STDIN to your clipboard. This was to make sure you don’t have any extra lines or spaces when you do your copy to the clipboard as public keys need to be exact.

This is where xclip comes in. xclip allows you to pipe content into your clipboard directly from the command line as well as outputting your clipboard. In terms of my example, it’s as simple as this:

cat id_rsa.pub | xclip

There’s only one problem with this example. Piping simply to xclip will only fill the clipboard you can use via xclip -o itself. Not your usual CTRL+V, or Right Click->Paste board. So how do you do that?

cat id_rsa.pub | xclip -selection c

Now when I go into Firefox or anywhere else, hitting CTRL+V I get the contents of id_rsa.pub. You can do this with ANY standard input to your terminal. File listings, file diff’s, drive space, etc .. you are not very limited.

Since I never plan to use xclip -o, I made a simple alias so I don’t have to constantly type -selection c, like so:

alias xclip=’xclip -selection c’

Now whenever I use the xclip pipe like I did in the first example it goes straight to my regular clipboard.

You may need to install xclip as it does not come default with Ubuntu. The xclip manual (man xclip) has a variety of other information I did not cover in my post, but this is all I personally need from it.

October 8, 2008

Best run of configure ever

Normally when you have to build from source and run a ./configure it’s usually boring old work, maybe a few fun options you have to set for your environment but eh, not my cup of tea. Thankfully, the guys at nmap made my morning just that much brighter by ending the configure with this:

Love it. Made me chuckle, first time I’ve ever noticed something like this (to be fair I generally don’t build from source unless I need to)

October 3, 2008

Two simple techniques to make your Django projects ultra portable

After moving around my Django projects between Windows and Linux boxes and different mySQL setups I spent some time looking for the best solution on making my project portable so I can throw it around wherever I want without much worry. Both these solutions are some-what known as I got them from the #django irc room (a super awesome resource!) but not much documentation is out on them.

1) Setting a ROOT_DIR and using it in settings.py

This is very simple. You want to setup a ROOT_DIR variable that basically consists of Python code that figures out what directory the file is in. The code is very simple:

2) Using a local_settings.py for easy moving around between environments

Another very simple but super useful trick. This allows you to over-ride any variables in settings.py for that specific machine. A simple use case for this would be that I have my development environment here on my Ubuntu machine but when I commit my project to SVN on the Debian server the mySQL details are different as it’s an entirely different server. So what I do is at the bottom of settings.py:

Then, setup settings.py so it matches your production environments settings (In this case, my Debian server) and create a new file called local_settings.py in the same directory. In this file, you can just place whatever vairables you want to over-ride. I have variables over-riding my MySQL and DEBUG settings to fit my local development (Ubuntu) environment. The key here is to not commit/send local_settings.py to production.

And that’s about it. Those two small changes make it very easy for my projects to move around. It makes it very nice to be able to commit even settings.py to your production environment and not worry about values not being correct.

If you know of any other good portability techniques I’d be glad to hear them in the comments section below, I’m still learning Django!