First, my ZSH prompt was already developed from the outset with that in mind. So, no additional hacking has been needed on that. There are some elements that I’m not too terribly excited about. I don’t care for the dark blue directories on a black background, and I don’t care for the yellow character devices on a white background. Using the Tango scheme for gnome-terminal makes both of those scenarios much more tolerable. However, I do have additional items that I want to put in my prompt, but that will be for a later post. Also, my GNU Screen hardstatus line also needed to be compatible. This wasn’t that big of a deal, as I only needed to apply some colors to a few elements. Hhere’s a couple screenshots showing both black and white backgrounds, and how the ZSH prompt inside looks in each. Note the GNU Screen hardstatus line is at the bottom of the terminal.

From Desktop Screenshots

From Desktop Screenshots

Second, my Irssi theme also needed to work well with both. As I’ve already blogged before, I was really, really impressed with the madcows theme. However, I didn’t care for a few elements, so I started hacking it, making my own changes. I’ve tried keeping the true nature of the theme, while still adding my own style. The theme was already largely compatible with my ZSH prompt colors, it just needed some adjustments here and there, before I was totally satisfied. Further, it looked like crap using a white background, so this needed some hacking as well. I think I’m overall happy with the result, although I’m sure I’ve missed many things (like DCC, or CTCP), so there’s likely much more hacking to go before it’s perfect. However, for the general day-to-day chat, it’s 95% there. Screenshots for both backgrounds below:

From Desktop Screenshots

From Desktop Screenshots

In a nutshell, the themes are compatible with xterm-color support on most terminals. Mainly, I’m using bold and normal weights on red, green, yellow, black, white and blue. Anything else takes the default color of the terminal itself, whether it be the foreground text or the background. So, as long as your TERM variable is set to “xterm-color” or something better, you should be okay.

This post wouldn’t be complete without the source for you to try it out. Here’s a compressed tarball for giving it a shot, and reporting anything you find in the comments, if you like.

Cheers!

You now have the following variables available in the shell script namepace: RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, BLACK, WHITE, BOLD_RED, BOLD_GREEN, BOLD_YELLOW, BOLD_BLUE, BOLD_MAGENTA, BOLD_CYAN, BOLD_BLACK, BOLD_WHITE, RESET. Using these variables, you can manipulate the output from “echo” and “printf” for your script. For example, here’s a screenshot using “echo” to print red, green and blue text to the screen. Notice that I’m using the “RESET” variable after the blue text to reset my prompt text back to normal. This may or may not be necessary, depending on how you configured your prompt, but it’s not a bad habit to get into.

Thought this might be helpful to the larger scripting community or for those sysadmins, such as myself, who would like a little variety added to their script output.

At the Utah Open Source Conference, I gave a BOF on Unix shells. The turnout was good, and we had a great discussion. I presented on my default prompt for ZSH, showing all the hidden features of the prompt. However, I had forgotten that I had removed battery status from my prompt, because I was depending on APM, which is no longer compiled in the kernel. A couple people have asked me since then why I’m depending on APM and not ACPI. I don’t have an answer, other than that was just what I coded. So, last night, I put up an ACPI implementation, and it works great. As with the APM implementation, if the battery percentage is less than 15%, the percentage display is red. If it’s less than 50% but greater than 14%, it’s yellow, and if it’s less than 100% but greater than 49%, it’s blue. If it’s 100%, or the tool “acpi” is not installed, then it doesn’t show up. Here’s a screenshot below:

While hanging out in our local LUG channel for the Ogden Area Linux Users Group, I got talking with Seth about prompts. He decided to change his, including adding the dog from Nethack randomly “moving” in the prompt. He also mentioned changing the color of the path if the present working directory was not writable. I really liked this idea, and decided to implement it in my prompt. Here’s a screenshot of that in action:

I change the path color to yellow if the present working directory is not writable, as it’s noticeable enough to catch your attention, but subtle enough to not get in the way, and be distracting.

As usual, if you want the source, here it is. Yes, it’s public domain, as mentioned in the code, so have at it.

First, I’m a big fan of SSH key authentication. Because I’m allowed to use SSH authentication, I have my public SSH key on all the servers in the datacenter. When my password is about to expire, I get an email notice once per day two weeks in advance. I can use this email as an opportunity to execute a script that will change all the passwords on all the servers for me. In the script, I’ll have it grab some data from /dev/urandom, and create a sha1sum of the input. An encrypted version of the hash will then be saved locally to disk, which will be encrypted with my GnuPG key, and emailed to myself, should I need the password for something other than SSH. Lastly, just so the password can’t be compromised, only the encrypted versions of the password remain on disk. The hashes themselves are shell variables that are cleared when the script exits. Further, I’ve changed the permissions on my home directory, where my SSH keys and GnuPG keys exist, such that everything sensitive is only accessible to myself. I realize that convenience comes at the sacrifice of a bit of security. My laptop is running full disk encryption, and my password to guard my account is strong. I am the only one on my machine, and I expect it to stay that way. As such, I’m not worried about anything getting compromised.

All of this is stored in a simple shell script, shown below. You will need the “expect” and “sha1sum” packages installed on your system before executing this script. You will need a GnuPG key pair generated for encrypting and decrypting data. You’ll need SSH keys created and distributed to each server beforehand. You should probably have your SSH keys added to your SSH agent, as well as your GnuPG key added to a GPG agent before executing the script, to save you some serious typing. I won’t cover that here, but Seahorse is a great utility for managing GPG and SSH keys. Of course, your SSH keys and GPG keys should be passphrase protected.

Initially, when I started writing this script, I wanted it to run in cron locally on my laptop. As I began building the script, I realized this wasn’t a secure move, for a couple of reasons. First, as already mentioned, I’m using SSH authentication using public key cryptography. All of my SSH keys are passphrase protected. I didn’t want to store the passphrase in the script, so I could automate the process, and I didn’t want to remove the passphrase or generate new keys that didn’t have a passphrase. Further, wanting to encrypt the data, and send it to myself via email required that I store my GnuPG passphrase on disk as well. I didn’t like this idea either, as I’m already storing the new and old encrypted passwords on disk from the script, and that’s enough. No need to compromise security any further. So, I’ll run this script by hand.

However, we have a problem. You will be typing passphrases galore in this script if you have a decent number of hosts to loop through. So, as mentioned, it would probably be best to take advantage of an SSH and GPG agent to cache your passphrases to ease the pain before executing the script.

Looking over the script a bit. First thing to note, is it is sending the same password to every server. You might not want this. If so, feel free to modify the script to fit your needs. Second, the sha1sum hash is never stored on disk. Rather, it’s just stored in variables OLDPASS and NEWPASS. The idea between the old passwords and the new passwords, is so we can provide the current password when updating, as well as the old.

We’re pulling from /dev/urandom as a source for semi-random data. Yes, you can pull from /dev/random if it makes you sleep better at night. Also, we’re not pulling a lot of data, because ultimately, the SHA1 hash will be strong enough as it is. You’ll notice too that because we’re using STDIN for our data source, the hash contains a space, asterisk and hyphen following the hash, and we’re keeping it. I figured no reason to remove it, as spaces, asterisks and hyphens are valid UNIX password characters. If your company has a more draconian password policy than mine does, requiring specifically more than say 3 or 5 non-alphanumeric characters, then just append those to the end of hash before encrypting to disk. Maybe something like the string “!@#$%”.

Lastly, we’re emailing the encrypted password to ourselves, so no worries about compromising there, plus that gives us an extra backup in case we lose our disk that is storing the encrypted passwords. This also gives flexibility to where we can retrieve the password, provided we have access to the Internet and our GPG keys. Then we’re using “expect” to send the passwd command to the server and send our old and new passwords as prompted for each server. You might need to change the expected prompt depending on your GNU/Linux or Unix derivative (“New RedHat password: ” for example).

That’s it! Simple enough. If you have any questions, or improvements, please post them in the comments. Thanks!

On Vim, the default mode is command mode, and when you go into a different mode, you’re notified, such as going into insert mode. However, with the ZSH, when you start up your prompt, you are in insert mode by default, and you must press your ESC key to go into command mode. So, seeing as though insert mode is default, rather than be notified constantly that I’m in insert mode, I’d rather be notified when I enter command mode. Also, I wanted a way to do this dynamically, so when I pressed my ESC key, I got an immediate visual that I entered command mode. The same event should happen when I go back into insert mode- my visual should disappear.

I wasn’t sure how to approach this, so after a bit of Googling, I discovered that I need to write a ZSH widget. I’ve never written a ZSH widget before. In fact, to be honest, I didn’t even know they existed. However, I was curious, and learned that I need to use the ‘zle -N’ command on a widget. By doing so, this widget will operate on the shell in real time, without waiting for the enter key to be pressed. This is exactly what I’m after. So, the only thing left to do was write a bit of logic handling when I’m in command mode, and when I’m not. Here’s the relevant bit of code:

Fairly straight forward I think. If the KEYMAP variable is set to “vicmd”, then we’re in command mode with vi on the shell, and we can set our VIMODE variable to ” M:command” (to match the rest of my prompt). If the KEYMAP variable is set to “main” or “viins”, then we can unset VIMODE. The way we do this is using inline ZSH substitution using ${VARIABLE/PATTERN} syntax. This says to search for our pattern anywhere within our variable. Check out the zshexpn(1) man page for more info and examples. Notice I’m running ‘zle reset-prompt’. Because this is a widget, I can take advantage of redrawing the prompt whenever I need. Now, the only thing left to do is put the $VIMODE variable in my prompt, and I’ll have a dynamic visual of when I enter command mode and when I leave it. Here’s some screenshot candy:

For the need-to-have-it readers, here’s the full source to my prompt. Just source the file in your .zshrc, and make sure that your TERM variable is set appropriately to handle terminal colors.

BASH is full-featured bloat. Yes, bloat. If System V Init scripts are relying on BASH to start their service, your boot process will be slower. DASH, in comparison is light and snappy, thus greatly improving the time it takes your computer to boot. If your scripts are adhering to POSIX standards, and are using /bin/sh rather than /bin/bash, you shouldn’t notice any problems. However, if your scripts are relying on /bin/bash features, such as popd or pushd, and you change the interpreter at the top of your script to /bin/sh, you’ll have some breakage.

For what it’s worth, this isn’t anything new with 8.04. DASH became the default in Ubuntu with 6.10, so we’ve had it in this manner for some time. If you would like to change it, then point the symbolic link from /bin/sh to /bin/bash rather than /bin/dash, and you’re done. However, as you may have noticed, it could cause some breakage if you Bourne-compatible scripts contain “Bashisms”.

Personally, I recommend the Z-shell (ZSH) to anyone looking for an alternative to DASH or BASH. Much more capable, flexible and configurable shell.

I’m running screen locally on my laptop (we’ll refer to it as SCREEN_L), and remotely on my server (we’ll refer to this one as SCREEN_R). For SCREEN_L, there is a ~/.screenrc that I use to show what screen window buffer I’m using via the “hardstatus” directive. My ~/.screenrc is thus:

aaron@kratos:~ 2609 % cat .screenrc
screen -t python 0
screen -t irssi 1
screen -t shell 2
screen -t notify 3
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]' 

That puts a nice status line at the bottom of my terminal, letting me know what screen buffer I’m in, as well as it’s title. However, I don’t want to run a ~/.screenrc under SCREEN_R. This just means yet another hardstatus line that I really don’t want (I value my pixels). Rather, I would like to be notified what screen window I’m under, if any, in my prompt. After a bit of digging, I came up with the solution.

First, the environment variable $WINDOW is keeping track of this automatically for me. For example:

aaron@kratos:~ 2610 % echo "\"$WINDOW\""
""
aaron@kratos:~ 2611 % screen
aaron@kratos:~ 2612 % echo "\"$WINDOW\""
"0"

Perfect! Now, to get it into my prompt. This is easy with adding a little if logic to our ~/.zshrc:

What am I doing here? Well, first off I’m checking to see if the $WINDOW variable is blank. I’m using x”$WINDOW” != x for a simple reason. Zsh is expecting a valid condition after ‘!=’. Unfortunately, an empty string isn’t satisfying it. So, I prepend the letter x to the $WINDOW variable, and test to make sure it doesn’t equal just ‘x’. Second, if $WINDOW equals anything other than ‘x’, a SCREEN variable is defined with the $WINDOW variable contents wrapped in parenthesis. This $SCREEN variable is then added to the prompt.

Now, I add this to my ~/.zshrc for my SCREEN_R, and I can see where I’m at in my screen session remotely without the need for a remote ~/.screenrc. Here’s the results, also showing off exit code:

aaron@kratos:~ 2614 % screen
aaron@kratos(0):~ 2615 % ping foo
ping: unknown host foo
aaron@kratos(0):~[2] 2616 %

Cheers!

In this example, the user is asked to enter input that can be any combination of letters and numbers, regardless of case. If the user enters punctuation, the test case fails, and the user is notified of such. Otherwise, the test case passes, and everyone is happy.

I want to call to your attention the cornerstone of this script, however:

The variable $compressed is holding only alphanumeric characters. This is done by taking the user input, and piping it to the stream editor sed. With sed, we are searching for any character in the string that is not a number or a letter. If such a character exists, we remove the character altogether. Thus, if $compressed removes any characters, then it does not match what the user entered, and our test will fail. If no characters were removed, then no punctuation exists in the input, and our test case will pass.

I thought this was most clever, and just had to share, hoping others benefit from this simple example. I also hope that Dave is not mad at me for taking an example, changing it up a bit, and presenting it on this blog. Thanks Dave.

Well, being a vim enthusiast, that just isn’t going to work. So, here’s something that I learned at my Ubuntu-Utah LoCo meeting that ended just 20 minutes ago:

Oh yeah. That’s better. When executed, you are in insert mode, and not command mode. So, to take advantage of the vim keyboard shortcuts, ‘esc’ or ‘ctrl-[‘ to get into command mode, and hack away! Make sure to add this to your ~/.bashrc.

You’re welcome.

aaron@poseidon:~$ bash irssi_notify.sh
irssi_notify.sh: 3: Syntax error: "done" unexpected (expecting "do")

The problem is a missing semi-colon after the word “message” just before the word “do”. So, it should read something like this:

...while read heading message;  do  /usr/bin/notify-send...

I have an updated copy. You can grab it here. Just replace ‘user@server’ with whatever is appropriate for you.

Because the Bash script is the most hackish of this notification solution, here is what I recommend doing with it:

• Obviously, save it in a location where you won’t delete it later.
• Pull up a terminal and run screen. If you don’t have screen installed, ‘sudo aptitude install screen’.
• Run the bash script ‘bash irssi_notify.sh’
• Detach the screen session by pressing ‘ctrl-a ctrl-d’ in that order.
• Exit the terminal you just pulled up

The script is now running in the background. When you change locations, you’ll need to stop the bash script before you leave your current location. So:

• Pull up a terminal and reattach your screen session: ‘screen -dr’
• Cancel the script with ‘ctrl-c’. It should still be running.
• Exit your terminal

Again, not the most elegant, but it works, and works well. Of course, if you have any questions, feel free to email me, comment on either post, or visit me in #ubuntu-us.

For this tutorial, it assumes that Irssi is running on a box separate from your current local machine that you have SSH access to. For example, at work, we have an inter-office server that is running an IRC server. I just SSH into that server from my workstation, fire up screen then Irssi, and connect to it. Irssi is running remotely from my desktop. This is also the case for my personal Irssi session. So, in other words, Irssi is running under screen remotely, and you connect to that session from any other computer via SSH.

First, there is fnotify.pl, a Perl script for Irssi to save the highlights you get in a channel to a file. Save this script to your ~/.irssi/scripts/ directory:

aaron@achilles:~$ mv fnotify.pl ~/.irssi/scripts

Now, if you want the script to run automatically when you launch Irssi, then create a directory called ‘autorun’ in the ~/.irssi/scripts/ directory, and create a symbolic link to fnotify.pl so Irssi starts it up automatically when loaded:

aaron@achilles:~$ cd ~/.irssi/scripts/autorun && ln -s ../fnotify.pl .

Once copied in, either start your Irssi session, or if it is already running, then execute the script in Irssi itself:

/RUN fnotify.pl

When running, it creates a file called ‘fnotify’ in the ~/.irssi/ directory. It is just a plain text file containing all the times you have been highlighted in a channel, one highlight per line.

We need to get the highlights in the appropriate channel to our desktop, so we can visually see them when we are not looking at Irssi itself. You will need notify-send to notify you when someone says your name in a channel. If not installed, install libnotify-bin (Ubuntu/Debian syntax below):

aaron@hercules:~$ sudo aptitude install libnotify-bin

Now, we just need to write a shell script to send us the GUI notifications. This can be done with a simple Bash script (yes, from the same page we got the Perl script for Irssi). Save it anywhere on your local box (not the box that is running the Irssi instance; like your workstation, for example) and execute it (here, I saved it as ‘irssi_notify.sh’).

In the script above, you need to replace ‘remote.system.somewhere’ with your server that you are connecting to. The script makes an SSH connection to the server that you specified, and parses through ~/.irssi/fnotify one line at a time. Each line gets its own notification. That line is then removed from the file, so it doesn’t continuously grow as you continue to get highlighted in channels.

There you go. That’s it! Pretty easy, but a little hackish. But that’s okay. Isn’t that what computers are all about? To automate human tasks? Besides, what fun would it be, if it weren’t hackish? At any rate, a screenshot of the notification results is shown below (you can see the notifications in the bottom-right of the screenshot). But first, a couple caveats:

1. If the screensaver kicks in, and you are highlighted in a channel, you will not receive a GUI notification. This is default behavior with libnotify-bin.
2. By default, Irssi only highlights the nick that mentioned your nick if your nick is first on the line. Otherwise, it is not the case. This can be fixed highlighting the nick that mentions your nick anywhere in the text. Do the following in Irssi:

/hilight -nick (your_nick)

Thanks to Clint for bringing this to my attention! Click for a larger screenshot.

For me, my first language that I sat down and learned in a formal setting was Java. However, I had TI, Casio, and HP calculators, as well as an Atari 800 that I would fiddle with, and program. So, Basic was really the first language that I toyed with. I just never sat down, and took the time to “learn” it.

So, for all the programmers, coders, script kiddies and developers out there, what is the 1st programming language that you learned? If applicable, leave a comment specifying the system that you learned the language on.

First, I should mention that this script comes with no warranty what-so-ever. Use it at your own risk. If you foul up your database or WordPress install, don’t come crying to me. Although this upgraded my 4 installations without hitch, this does not necessarily mean that it will work for you. Please use caution when upgrading the files and the database. If you do run into problems, I will try to provide necessary support as possible. However, I am very busy, so it may be faster for you to figure out what happened, and to fix it on your own. You’ll learn better that way anyway.

Next, this script follows the detailed instructions as closely as possible. Namely:

• Your existing WordPress install is backed up, just in case.
• All databases are backed up.
• All necessary and important files (.htaccess, wp-config, etc) and directories are backed up.
• The latest release is downloaded.
• All files are upgraded.

Of course, it is your job to navigate your browser to the appropriate PHP upgrade page for every WordPress installation that is upgraded, and verify that all plugins, permalinks and themes work.

At any rate, here is the code: a simple Bash script. The version of the script is 0.1.2.

The Perl code I used to accomplish the task is as follows (please take note, that WordPress loves to parse tags, even if contained within <code> tags. WordPress also likes to lowercase the tag, so in Perl, file handles will be in lowercase):

Just for fun, a buddy of mine mentioned to code it in Ruby, and compare results. Seeing as though I have never coded a Ruby script in my life, I was a bit worried. However, it wasn’t too bad. I just had to cure my itch to put a $ in front of all my variables. Anyway, heres the Ruby code, following as closely as possible to the Perl code:

Ok. As you can see, the code is fairly similar. The algorithms the same. Running the script takes a mere second or two, and the file comes out correct. However, I was curious about execution speed, so I decided to pit one script against the other, time them, and see what happens. Here are my results

aaron@hercules:~/Desktop$ time perl weight.pl
Processed: 5394

real    0m1.386s
user    0m1.304s
sys     0m0.048s
aaron@hercules:~/Desktop$ time ruby weight.rb
Processed: 5394

real    0m2.180s
user    0m1.992s
sys     0m0.124s

Am I reading this correctly? Perl is almost 60% faster at execution with this code than Ruby? I thought Ruby was supposed to have exceptional file handling. Better than Perl, even. However, I have also heard that the Ruby devs are more concerned about functionality than speed, which should be expected. Still, that’s a serious speed factor. If I was worried about speed here, Perl, in this case, would win out.

At any rate, this was a fun little exercise to stretch my scripting muscles, and to learn a bit of Ruby. I’m curious if I can make the scripts more efficient. If you know how, comment below, or contact me.

Well, I set it up again here on pthree.org. Why, you ask? Honestly, I don’t know. Probably more for the geek factor than anything. But at any event, it’s there, and cool.

Writing the code was really easy, actually. The only trouble I had was setting up SSH to allow password-less secure copy. Once that was up, a simple Bash script to capture the screenshot, resize the image, and send it to the server. Here are the steps I followed to get my Desktop Cam up and running:

1. Generate an SSH DSA key on the client that will be sending the image to the server. The command was ‘ssh-keygen -t dsa’.
2. Append id_dsa.pub to the file ‘authorized_keys’ on the server. If the file doesn’t exist, create it.
3. Create the Bash script with a simple while loop that executes creating the image and copying to the server every 30 seconds.
4. Write the HTML for displaying the screenshot.
5. Write the JavaScript to refresh the image every 30 seconds also.

For the Bash code, it was easy (text wrapped as necessary):

The JavaScript to reload the image was just as easy:

The HTML in the post was even easier:

That’s it! Probably what kept me hung up the most was getting WordPress to play nicely with inline JavaScript. After a bit of searching and digging around though, I found the trick to getting JavaScript to work.

Anyway, there you go. Fairly simple code, easy to implement and low overhead.