Desktop Notifications for Irssi in Screen through SSH in Gnome Terminal

I’m usually on IRC, but I don’t often notice incoming pings until after the fact. I had to both write, and modify various scripts to get what I wanted, but now it’s all done, and you can benefit from my hacking by following along…

The Setup

Laptop -> Gnome-Terminal -> SSH -> Screen -> Irssi

This way, I’m connected to IRC, even when my laptop isn’t. I run irssi in a screen session on an SSH server that I manage, and I use gnome-terminal on my laptop. If you don’t understand this setup, then you’ll need to get more comfortable with these tools first.

Fnotify

The first trick is getting irssi to store notifications in a uniform way. To do this, I modified an irssi script called fnotify. My changed version is available here. Installation is easy:

# on your ssh server:
cd /tmp; wget https://dl.dropboxusercontent.com/u/48553683/irssi/fnotify.pl
cp /tmp/fnotify.pl ~/.irssi/scripts/
# in irssi:
irssi> /load perl
irssi> /script load fnotify

When someone sends you a direct message, or highlights your nick on IRC, this script will append a line to the ~/.irssi/fnotify file on the SSH server.

Watching fnotify

On your local machine, we need a script to tail the fnotify file. This was surprisingly hard to get right. The fruit of my labour is available here. You’ll want to copy this script to your local ~/bin/ directory. I’ve named this script irssi-fnotify.sh. This script watches the remote fnotify file, and runs notify-send and paplay locally to notify you of any incoming messages, each time one comes in.

SSH Activation

We want the irssi-fnotify.sh script to run automatically when we connect to our SSH server. To do this, add the following lines to your ~/.ssh/config file:

# home
Host home
    HostName home.example.com
    PermitLocalCommand yes
    LocalCommand ~/bin/irssi-fnotify.sh --start %r@%h

You might also want to have other directives listed here as well, but that is outside the scope of this article. Now each time you run:

ssh home

The irssi-fnotify.sh command will automatically run.

Magic

I’ve left out some important details:

• The LocalCommand that you use, must return before ssh will continue. As a result, it daemonizes itself into the background when you invoke it with –start.
• My irssi-fnotify.sh program watches the parent ssh $PID. When it exits, it will run a cleanup routine to purge old notifications from the fnotify file. This requires a brief SSH connection back to the server. This is a useful feature!
• You may wish to modify irssi-fnotify.sh to paplay a different alert sound, or to avoid making noise entirely. The choice is yours.
• When irssi-fnotify.sh runs, it will tail the fnotify file over ssh. If there are “unread” messages, tail will try to “download” up to ten. You can edit this behaviour in irssi-fnotify.sh if you want a larger initial backlog.
• The irssi-notify.sh script doesn’t attempt to prevent flooding, nor does it filter weird characters from incoming messages. You may want to add this yourself, and or /kb users who cause you to need these features.

Here’s a little screenshot (with shameless plug) of the result in action:

Here’s an example of how this helps me to be more responsive in channel:

helping out in #gluster

I hope you found this useful.

Happy Hacking,

James

Show current git branch in PS1 when branch is not master

Short post, long command…

I’ve decided to start showing the current git branch in my PS1. However, since I don’t want to know when I’m on master, I had to write a new PS1 that I haven’t yet seen anywhere. Add the following to your .bashrc:

PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if [ -e /usr/share/git-core/contrib/completion/git-prompt.sh ]; then
    . /usr/share/git-core/contrib/completion/git-prompt.sh
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w$([ "$(__git_ps1 %s)" != "" -a "$(__git_ps1 %s)" != "master" ] && (echo -e " (\[33[32m\]"$(__git_ps1 "%s")"\[33[0m\])") || echo "")\$ '
fi

This keeps my PS1 short for when I’m hacking on personal repositories that only have a single branch. Keep in mind that you might have to change the path to git-prompt.sh depending on what OS you’re using.

Example:

james@computer:~/code/puppet$ cd puppet-gluster
james@computer:~/code/puppet/puppet-gluster$ git checkout -b cool-new-feature
Switched to a new branch 'cool-new-feature'
james@computer:~/code/puppet/puppet-gluster (cool-new-feature)$ # tada !

The branch name is coloured to match the default colours that git uses to colour branches.

Happy hacking,

James

 

Mothers day hacks

Firstly Happy Mother’s day to my mother.

Google is, as usual, busily releasing doodles. Today, the doodle takes you through a Rube Goldberg -esque sequence, giving you four decisions to make along the way. Each decision gives you one of three different choices, and at the end, a unique drawing is displayed. I expect:

3 * 3 * 3 * 3 = 81

different permutations. At the end of the process, you can print your image. I got directed to:

https://www.google.ca/logos/2013/mom/print/3311.html

which suspiciously has a four digit filename composed of three’s and ones. Inspecting the file in firefox shows that the main image url is:

https://www.google.ca/logos/2013/mom/hdcards/3311.jpg

with a similarly suspicious “3311“. I decided that I wanted to see all the permutations without having to refresh google’s page. Jumping to a terminal, and using some bash expansion magic:

$ cd /tmp
$ mkdir hack1
$ cd hack1/
$ wget https://www.google.ca/logos/2013/mom/hdcards/{1..3}{1..3}{1..3}{1..3}.jpg
[snip]
FINISHED --2013-05-12 07:07:22--
Total wall clock time: 1m 23s
Downloaded: 81 files, 138M in 1m 19s (1.75 MB/s)

I am pleased to see that 81 files have downloaded, and that they’re all unique:

$ md5sum * | sort | uniq | wc -l
81

and all png’s:

$ file * | awk '{print $2}' | sort | uniq | wc -l
1
$ file * | head -1
1111.jpg: JPEG image data, EXIF standard

Now I can very easily browse through the images with eog, and select my favourite.

Hope this has been instructive,

Happy hacking,

James

 

Knowing when to release and deploy your code (…and a mini script)

Knowing when to release and deploy your code can turn into a complicated discussion. In general, In general, I tend to support releasing early and often, for some value of $early and $often. I’ve decided to keep this simple and introduce you to one metric that I use…

I think that I am fairly diligent in adding plenty of comments to my source code. I might even sometimes add too many. I create plenty of XXX, FIXME, or TODO tagged comments as reminders of things to work on.

To me, XXX represents an important problem that should get looked at or fixed; FIXME, reminds me that I should definitely look into something, and finally, TODO gives me homework or things to pursue when I’m in need of a new project.

I try to resolve most if not all XXX tagged comments before making a 0.1 release, FIXME’s to consider something very stable, and a lack of TODO’s mean something is completely done for now.

To count all these, I wrote a little tool that greps through the top-level directories in my ~/code/ folder, and displays the results in a table. Feel free to give it a try, and use it for your own projects.

While I don’t see this as a particularly game changing utility, it scratches my itch, and helps me keep up my bash skills. The code is available here. Let me know if you have any improvements, or if the source isn’t enough documentation for you.

Happy hacking,

James

running your file manager from a terminal

I do a lot of my work in a terminal. For the unfamiliar, this might seem strange, however once you’re comfortable with your shell, this is the best place to be. I don’t restrict myself to it though. I often want to spawn a file manager, or a graphical text editor. When I run nautilus, I usually see something like this:

james@computer:~/some/awesome/directory$ nautilus .
Initializing nautilus-open-terminal extension
Shutting down nautilus-open-terminal extension
james@computer:~/some/awesome/directory$

This is useful, because I can open a file browser right where I want it, it’s annoying, because nautilus runs in that terminal until I close it. (This doesn’t happen if the nautilus process is always running, but since GNOME 3, it isn’t.)

My solution is a short bash script that runs nautilus, and leaves your terminal alone. I named my script nautilus, and placed it inside my ~/bin/. Here is the script:

#!/bin/bash
# run nautilus from a terminal, without being attached to it; similar to nohup
# use the full path of nautilus to avoid it calling itself (recursion!)
{ `/usr/bin/nautilus "$@" &> /dev/null`; } &

I hope this is useful for you too. Feel free to do the same for gedit, nemo, and any other app which you often find convenient to run from the terminal. You can generalize this by leaving out the nautilus program:

#!/bin/bash
if [ "$1" == "" ]; then
        echo "usage: ./"`basename $0`"  (to run a command nohup style)"
        exit 1
fi
# do a nohup bash style according to:
{ `"$@" &> /dev/null`; } &

I name the above script run.sh, and it helps me out from time to time, when I don’t want to touch my mouse.

In case you haven’t heard about it, there’s also an open-terminal extension for nautilus and nemo which lets you get to a terminal, from your file manager. A quick internet search should help you install it.

If you found this information useful, please let me know, and as always,

Happy hacking,

James

PS: If you plan to do this for gedit, you probably want to preserve stdin, so that you can still pipe things in. To do this, you’ll probably want:

{ `/usr/bin/gedit "$@" &> /dev/null`; } < /dev/stdin &    # accept stdin too!

scary cool bash scripting inside a Makefile

Makefiles are both scary and wonderful. When both these adjectives are involved, it often makes for interesting hacking. This is likely the reason I use bash.

In any case, I digress, back to real work. I use Makefiles as a general purpose tool to launch any of a number of shell scripts which I use to maintain my code, and instead of actually having external shell scripts, I just build any necessary bash right into the Makefile.

One benefit of all this is that when you type “Make <target>”, the <target> can actually autocomplete which makes your shell experience that much more friendly.

In any case, let me show you the code in question. Please note the double $$ for shell execution and for variable referencing. The calls to rsync and sort make me pleased.

rsync -avz --include=*$(EXT) --exclude='*' --delete dist/ $(WWW)
# empty the file
echo -n '' > $(METADATA)
cd $(WWW);
for i in *$(EXT); do
b=$$(basename $$i $(EXT));
V=$$(echo -n $$(basename "`echo -n "$$b" | rev`"
"`echo -n "$(NAME)-" | rev`") | rev);
echo $(NAME) $$V $$i >> $(METADATA);
done;
sort -V -k 2 -o $(METADATA) $(METADATA) # sort by version key


The full Makefile can be found inside of the bash-tutor tarball.

piping data through ssh

not that what i’m about to tell you is brilliant, new or revolutionary, however i thought i’d mention it in case you’re not doing it. also feel free to let me know if there is a better way.

problem: i have some stdout which comes from a command and i want it in a file on another machine.

i could first send it to a temp file, scp that over, and then remove the temp file; but instead, i’ll just:

echo here is some stdout | ssh example.com tee filename

which gives me the added bonus of seeing the contents fly by my screen as they get sent through tee.