Make the Linux chkconfig service list easier to read

October 4, 2013 Programming, Unix 1 comment , ,

If you run a Linux box, and you want to see what services start up at which level, you use runlevel:

$ chkconfig
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:off   4:off   5:off   6:off
blk-availability        0:off   1:on    2:on    3:on    4:on    5:on    6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:off   4:off   5:off   6:off

Boy is that hard to read at a glance. All the “on” and “off” look very similar to each other, and that blk-availability service’s length screws up the tabbed columns. I decided I needed a better way, which I called cclist.

$ cclist
  2345  acpid
   345  atd
  2     auditd
 12345  blk-availability
 12345  cpuspeed
  2345  crond
  2     cups

Here’s the code to ~/bin/cclist:


open( my $fh, '/sbin/chkconfig --list |' ) or die "Can't open chkconfig: $!";

while (<$fh>) {
    if ( /^(\S+)(\s+\d:o(n|ff)){7}/ ) {
        my @cols = split;
        my $service = shift @cols;
        for ( @cols ) {
            my ( $level, $status ) = split /:/;
            print $status eq "on" ? $level : " ";
        print "\t$service\n";
    else {

My bash prompt with git/svn branch+status display

April 24, 2013 Unix 2 comments , , , ,

After spending a few hours last night switching between three different branches in the ack2 project, and typing “git br” over and over, I decided I needed to put branch status in my bash prompt. The only question was: Which one would I steal? Fortunately, Rob Hoelz was online and I mentioned it to him and he handed me his, so I stole it and also added Subversion support as well.


# Adapted from from https://github.com/hoelzro/bashrc/blob/master/colors.sh

function __prompt
    # List of color variables that bash can use
    local BLACK="\[\033[0;30m\]"   # Black
    local DGREY="\[\033[1;30m\]"   # Dark Gray
    local RED="\[\033[0;31m\]"     # Red
    local LRED="\[\033[1;31m\]"    # Light Red
    local GREEN="\[\033[0;32m\]"   # Green
    local LGREEN="\[\033[1;32m\]"  # Light Green
    local BROWN="\[\033[0;33m\]"   # Brown
    local YELLOW="\[\033[1;33m\]"  # Yellow
    local BLUE="\[\033[0;34m\]"    # Blue
    local LBLUE="\[\033[1;34m\]"   # Light Blue
    local PURPLE="\[\033[0;35m\]"  # Purple
    local LPURPLE="\[\033[1;35m\]" # Light Purple
    local CYAN="\[\033[0;36m\]"    # Cyan
    local LCYAN="\[\033[1;36m\]"   # Light Cyan
    local LGREY="\[\033[0;37m\]"   # Light Gray
    local WHITE="\[\033[1;37m\]"   # White

    local RESET="\[\033[0m\]"      # Color reset
    local BOLD="\[\033[;1m\]"      # Bold

    # Base prompt
    PS1="$LCYAN\h:$YELLOW\w$LCYAN \\\$$RESET "

    local dirty
    local branch

    # Look for Git status
    if git status &>/dev/null; then
        if git status -uno -s | grep -q . ; then
        branch=$(git branch --color=never | sed -ne 's/* //p')

    # Look for Subversion status
        svn_info=$( (svn info | grep ^URL) 2>/dev/null )
        if [[ ! -z "$svn_info" ]] ; then
            branch_pattern="^URL: .*/(branch(es)?|tags)/([^/]+)"
            trunk_pattern="^URL: .*/trunk(/.*)?$"
            if [[ $svn_info =~ $branch_pattern ]]; then
            elif [[ $svn_info =~ $trunk_pattern ]]; then
            dirty=$(svn status -q)

    if [[ ! -z "$branch" ]]; then
        local status_color
        if [[ -z "$dirty" ]] ; then
        PS1="$LCYAN($BOLD$status_color$branch$LCYAN)$RESET $PS1"

if [[ -z "$PROMPT_COMMAND" ]]; then

Just drop that into your ~/.bash directory as prompt.sh, and then add

source ~/.bash/prompt.sh

to your .bashrc. Now you have color-coded branch names: red for dirty, green for clean.

ack 2.0 has been released

April 19, 2013 Open source, Programming, Unix 6 comments ,

ack 2.0 has been released. ack is a grep-like search tool that has been optimized for searching large heterogeneous trees of source code.

ack has been around since 2005. Since then it has become very popular and is packaged by all the major Linux distributions. It is cross-platform and pure Perl, so will run on Windows easily. See the “Why ack?” page for the top ten reasons, and dozens of testimonials.

ack 2.0 has many changes from 1.x, but here are four big differences and features that long-time ack 1.x users should be aware of.

  • By default all text files are searched, not just files with types that ack recognizes. If you prefer the old ack 1.x behavior of only searching files that ack recognizes, you can use the -k/--known-types option.
  • There is a much more flexible type identification system available. You can specify a file type based on extension (.rb for Ruby), filename (Rakefile is a Ruby file), first line matching a regex (Matching /#!.+ruby/ is a Ruby file) or regex match on the filename itself.
  • Greater support for ackrc files. You can have a system-wide ackrc at /etc/ackrc, a user-specific ackrc in ~/.ackrc, and ackrc files local to your projects.
  • The -x argument tells ack to read the list of files to search from stdin, much like xargs. This lets you do things like git ls | ack -x foo and ack will search every file in the git repository, and only those files that appear in the repository.

On the horizon, we see creating a framework that will let authors create ack plugins in Perl to allow flexibility. You might create a plugin that allows searching through zip files, or reading text from an Excel spreadsheet, or a web page.

ack has always thrived on numerous contributions from the ack community, but I especially want to single out Rob Hoelz for his work over the past year or two. If it were not for Rob, ack 2.0 might never have seen the light of day, and for that I am grateful.

A final note: In the past, ack’s home page was betterthangrep.com. With the release of ack 2.0, I’ve changed to beyondgrep.com. “Beyond” feels less adversarial than “better than”, and implies moving forward as well as upward. beyondgrep.com also includes a page of other tools that go beyond the capabilities of grep when searching source code.

For long time ack users, I hope you enjoy ack 2.0 and that it makes your programming life easier and more enjoyable. If you’ve never used ack, give it a try.

Programmers, please take five minutes to provide some data for an experiment

April 19, 2012 Programming, Unix 30 comments

Whenever people talk about ack, there’s always a discussion of whether ack is faster than grep, and how much faster, and people provide data points that show “I searched this tree with find+grep in 8.3 seconds, and it took ack 11.5 seconds”. Thing is, that doesn’t take into account the amount of time it takes to type the command.

How much faster is it to type an ack command line vs. a find+xargs line? I wanted to time myself.

Inspired by this tweet by @climagic, I wanted to find out for myself. I used time read to see how long it would take me to type three different command lines.

The three command lines are:
A: ack --perl foo
B: find . -name '*.php' | xargs grep foo
C: find . -name '*.pl' -o -name '*.pm' | xargs grep foo

So I tried it out using time read. Note that it’s not actually executing the command, but measuring how long it takes to hit Enter.

$ time read
find . -name '*.pl' -o -name '*.pm' | xargs grep foo

real    0m8.648s
user    0m0.000s
sys     0m0.000s

For me, my timings came out to average about 1.4s for A, 6.1s for B and 8.6s for C. That was with practice. I also found that it is nearly impossible for me to type the punctuation-heavy B and C lines without making typos and having to correct them.

So I ask of you, dear readers, would you please try this little experiment yourself, and then post your results in the comments? Just give me numbers for A, B and C and then also include the name of your favorite Beatle so I know you actually read this. Also, if you have any insights as to why you think your results came out the way they did, please let me know.

At this point I’m just collecting data. It’s imperfect, but I’m OK with that.

  • Yes, I’m sure there’s another way I could do this timing. It might even be “better”, for some values of “better”.
  • Yes, I know that I’m asking people to report their own data and there may be observational bias.
  • Yes, I know I’m excluding Windows users from my sample.
  • Yes, I know it’s possible to create shell aliases for long command lines.
  • Yes, I know that the find command lines should be using find -print0 and xargs -0.
  • Yes, I know that some shells have globbing like **/*.{pl,pm}.

Note: I’ve heard from a zsh user that time doesn’t work for this because it’s a shell function, but /usr/bin/time does work.

Thanks for your help! I’ll report on results in a future post.

Dennis Ritchie, pioneer of programming, has died

October 13, 2011 Programming, Unix 1 comment , ,

Dennis Ritchie, pioneer of programming, creator of the C programming language and one of the creators of UNIX, has died.

Tim Bray said it best: “It is impossible — absolutely impossible — to overstate the debt my profession owes to Dennis Ritchie. I’ve been living in a world he helped invent for over thirty years.”  If you’ve written a program on any computer in any language since the mid-1970s, you’ve been influenced by the man’s work.

In his honor, the choir will now sing one of my favorite programming songs, “Write in C”.

When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom:
“Write in C.”

And as the deadline fast approaches,
And bugs are all that I can see,
Somewhere someone whispers:
“Write in C.”

Write in C, write in C,
Write in C, yeah, write in C.
Don’t even think of COBOL
Write in C.

If you’ve just spent 30 hours
Debugging some assembly,
Soon you will be glad to
Write in C.

I used to write a lot of FORTRAN,
For science it worked flawlessly.
Try using it for graphics!
Write in C.

Write in C, write in C,
Write in C, oh, write in C.
BASIC’s not the answer,
Write in C.

Now, let’s move forward with our lives, and remember to always place the opening brace of a block on the same line as the control statement, as he would have wanted it.

The touch command does more than just create empty files

July 10, 2011 Unix 6 comments , ,

Beginners to Unix/Linux learn about the touch command as a way to create an empty file.

$ ls -l /tmp/foo
ls: /tmp/foo: No such file or directory

$ touch /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul 10 11:56 /tmp/foo

But there’s more to it than that.  The main job of touch is to modify the timestamps on a file.  Creation of a file is almost a side effect.

The -t argument to touch lets me specify a date and time to set on the file.

$ ls -l /tmp/foo
ls: /tmp/foo: No such file or directory

$ touch -t 201107010930 /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul  1 09:30 /tmp/foo

If I don’t specify a date and time, then the current date and time are used.

$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul  1 09:30 /tmp/foo

$ touch /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 andy  wheel  0 Jul 10 11:58 /tmp/foo

You can also use the timestamp from another file and apply it to another file by using the -r switch.

$ ls -l /tmp/someotherfile
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/someotherfile

$ touch -r /tmp/someotherfile /tmp/foo /tmp/foo2 /tmp/foo3
$ ls -al /tmp/
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/foo
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/foo2
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/foo3
-rw-r--r--  1 andy  wheel  0 Aug 12  2005 /tmp/someotherfile

man touch will give you all the details.