Monthly Archives: October 2013

Countdown timer shell script

I made a small countdown script for the shell. It goes as follows:

Some tricks used in the script include:

  1. echo -ne "blah blah \r" was used to write in the same line over and over
  2. That 19800 is the time difference from GMT 0.0 in seconds. In Sri Lanka, it’s 5.30 hrs. Yes, we’re dealing with epoch time here, but still trying to figure out why we need to offset the time difference. :???:
  3. notify-send sends a desktop notification
  4. zenity --info pops up a message box

You can also add a sound to play with mplayer.

Resuming a failed scp transfer

Every now and then I scp some large files and the connection drops half way through. :neutral: Thanks to rsync it’s pretty easy to resume the transfer.

rsync --partial --progress --rsh=ssh user@ip:remotepath localpath

Breakdown:

--partial – this lets rsync know that it should keep the already downloaded partial files and download only the remainder
--progress – show the progress of the transfer
--rsh=ssh – use the ssh protocol
user@ip – remote machine. This might be the alias you’ve given it in your ssh config file.
remotepath – path to the file in the remote machine
localpath – path to the partially-downloaded local file

ShellCheck – static analyzer for shell scripts

Just came across ShellCheck. From its About page:

ShellCheck is a static analysis and linting tool for sh/bash scripts. It’s mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.

Interestingly, the tool’s completely written with Haskell. You can copy/paste the script on the site, or even install it so you can conveniently check shell scripts every now and then. You need cabal to have installed to compile the source. On Debian, you can install the package haskell-platform to install cabal.

Installing rupa/z

z is a command-line tool that would make jumping around your favorite directories much, much faster. It sits in the background and monitors where you cd to often, like a creep. 8-O And whenever you need to change to that ~/pictures/lol/cats directory, all you have to type in is z cats and you’ll be there. How it achieves this feat is by overriding the default cd‘s functionality with a custom shell function. Bad, bad z. :twisted:

Install rupa/z somewhere in your $PATH, say ~/bin.

cd ~/bin
curl -O https://raw.githubusercontent.com/rupa/z/master/z.sh
chmod +x z.sh
source z.sh

You might get a ‘no such file or directory’ error the first time, just ignore that. z works in both bash and zsh. You might need to add the source ~/bin/z.sh line in your .bashrc or .zshrc so it starts up with your shell session.

Update:

Optionally, you can install the z man page as well. Jump to a directory in your MANPATH (you can find these using the command man -w) and download the man file.

cd /usr/local/man/man1
sudo curl -O https://raw.githubusercontent.com/rupa/z/master/z.1

Reaching pi

This is old, but randomly came across this TeX FAQ which explains why the version numbering of TeX is reaching pi:

Knuth has declared that he will do no further development of TeX; he will continue to fix any bugs that are reported to him (though bugs are rare). This decision was made soon after TeX version 3.0 was released; at each bug-fix release the version number acquires one more digit, so that it tends to the limit π (at the time of writing, Knuth’s latest release is version 3.1415926). Knuth wants TeX to be frozen at version π when he dies; thereafter, no further changes may be made to Knuth’s source. (A similar rule is applied to Metafont; its version number tends to the limit e, and currently stands at 2.718281.)

Reaching π isn’t as easy as it sounds though. So many iterations and still you won’t be there. You can’t achieve perfection.

Trying out the cheat codes before you play the game

Did I mention how much I love analogies? Can’t stop but post when I come across a good one. :roll:

From /r/vim:

I have two half brothers who came along when I was 11. When they were old enough to play video games, I got them a good one, and just to round out the present and make it a two-stack of wrapped gifts, I threw in the big walkthrough/cheats guide book. I’d had a few of those back in the mid/late 80s for Nintendo, which I would turn to when I got really stuck, or after I beat a game to go back and have some additional fun cheating.

To my horror, they ran into the other room, put in the game, then opened the book and found the cheats and put in several cheat codes before even playing! They wouldn’t even hear of not doing it. It’s what “everyone” did. I’m fine with cheating for fun like that – I did it – but at least play for awhile so you can tell you are cheating. How are you going to think “Ah, that’s much better now that I don’t die as often” unless you’ve died often for a bit to set a baseline? How are you going to think “Wow, the light saber makes this level ridiculously easy” unless you knew that there is no light saber in the normal game, and it’s actually a difficult level without that easter egg?

How will you even know what Vim even is if you’ve immediately bolted on a bunch of upgrades? How are you going to ask for help? “Hey guys, I’m not sure if this is a Janus thing, or something from my coworker’s configuration, or one of the 15 plugins I installed, because some guide said they were cool (I have no idea, I’ve never really used Vim before!), but, uh… when I press ‘b’, isn’t it supposed to go back a word? It’s doesn’t.”

Yeah? Well, good luck.

Don’t fork

The gist a simple git branching model has gained much popularity lately. The author mentions some drastic changes to the normal git flow like merging changes from feature branches straight into master. This is necessary to maintain simplicity.

There are some notes to the end of the gist. Among them is one titled “Don’t fork. Push feature branches to main repo.”.

Sometimes I see people forking repositories in order to issue pull-requests. Yes, you may have to do this when contributing to open-source projects you don’t regularly contribute to. But, if you are a contributor, or working in the same org, get push rights on the repo and push all your feature branches to it. Issue pull requests from one branch to another within the same repo.

Because the whole fork and pull-request mechanism can be devastating sometimes, you don’t need to consider such sophisticated schemes for small teams. Let’s face it, only a fraction developers out there have the itch to really learn the tools they are using. You’re lucky if more than half of your team is well-versed with at least the basic git commands.

When you can afford it, it’s always a good idea to have a central repo and give everyone write permissions. You can even fine-tune the permissions to specific branches if your git server runs gitolite. AFAIK, this is not possible with github or gitlab.

Subscription URLs for popular feed readers

Here are the feed subscription URLs to add new feeds to some of the most popular feed readers out there:

Newsblur
http://www.newsblur.com/?url=%s

Feedly
http://cloud.feedly.com/#subscription%2Ffeed%2F%s

The Old Reader
http://theoldreader.com/feeds/subscribe?url=%s

Bloglines
http://www.bloglines.com/login?r=/sub/%s

The %s should be replaced by the feed URL you are going to add. You can use these to add custom readers to extensions like Chrome’s RSS Subscription Extension.

I couldn’t find the URLs for Digg Reader and Blogovin which seem to be popular among many. :???: If your feed reader doesn’t give a good public API it isn’t worth staying at anyway. ;)

C++ as a scripting language

Jussi Pakkanen of Canonical writes:

With the release of C++11 something quite extraordinary has happened. Its focus on usable libraries, value types and other niceties has turned C++, conceptually, into a scripting language.

I don’t necessarily agree with everything on that post, but one thing’s clear: C++ isn’t what it used to be. With C++11 things have changed, a lot.

If I was to write a script it’d be python or a shell script, I wouldn’t even consider C++. But then again, if that is some script you need to run every once in a while or one that has to be run over and over again within a short period of time, why not just write it in C++ and compile to native code? It would run faster than any other scripting language would, without waiting for some runtime or VM to load up.

And now you don’t need to learn the ins and outs of pointer arithmetic to do this. :wink:

Python import and easter eggs

Amir Rachum has a good primer on python’s import. If you’re new to python you should definitely give it a go.

The post ends up with some cool import easter eggs.

import antigravity
import this
from __future__ import braces
import __hello__
from __future__ import barry_as_FLUFL

Try them yourself in a REPL :)