#ifdef linux

Job Logging in Upstart The big Upstart feature in Ubuntu Precise is "job logging" (in fact, it turned out to be a significantly bigger feature than we'd originally envisaged :-). This had been a wishlist item for some time and a lot of folk were very keen to see this implemented. All system jobs now have their stdout and stderr logged automatically  by default to a text file in directory  /var/log/upstart/ . Why did we make this the default? Surely daemons and services don't generally write any output? True, but when they do produce output, it is worth capturing since it has a very high chance of being an error message. And errors should not be ignored. For jobs that do not produce any output, there is minimal overhead and of course no log is written. The logger actually uses pseudo-ptys just like  script(1) , xterm(1) , expect(1) ,  screen(1)  et al . This is advantageous for a number of reasons, but from the logging perspective the biggie i...

Linux provides a plethora of useful trace tools. Two of the most command and the most useful being strace , for tracing system calls and ltrace that traces library calls (it can also trace system calls). There a quite a few other exotic and experimental tools available but there seemed to me there was a gap in the coverage... Recently, I had cause to need an application-level trace. For the problem at hand, I didn't care a hoot about system calls or indeed library calls -  I wanted a trace log file that showed a call to " main ", and then entries for all the other functions I had written in the application . A quick search around didn't reveal much, but some lateral thinking saved the day. What tool can display application-level function names? gdb of course! The question was how to coerce it into working as a trace tool. It's actually very simple. What you do is this: Set breakpoints on every function in your application. Make GDB display the frame wheneve...

I use the mighty vim editor for most of my coding. I have a heavily customized setup which has evolved over quite a few years. However, it is by no means a static setup as I keep finding new scripts and tricks (and of course Bram keeps on adding extra goodness with each release). Recently, I was hacking through a lot of C code containing lots of debug cruft (log function calls, commented out bits and pieces, etc). The problem was I couldn't get a feel for the code as all the debug was too distracting. The question popped into my head, "can I hide all this stuff?" A number of folk have come up with ways to "hide" the data you don't want to see in Vim using folds (" :help fold " in Vim). However, that wasn't what I wanted as folds also introduce their own "visual noise". I just wanted this stuff gone . What I came up with is a complete hack, but it suited my purpose rather well: I changed the colour of the regex's matching the ...

If like me you gravitate towards minimal applications, check out the uzbl web browser. It's based on webkit , supports Java, Flash, CSS, Javascript, etc and has full keyboard control. Added to this, it is fully configurable - it has a standard ASCII config file. This page shows the default keybindings. uzbl is a godsend to those of us who are too lazy (or busy) to take their hands away from the keyboard to reach for the pesky mouse. To install: sudo apt-get install uzbl I'm running uzbl-tabbed (which comes as part of the uzbl package). As the name suggests, this supports tabs. However, I was scratching my head trying to work out how to open a new link in a new tab , rather than a new window . The answer is simplicity itself (once you know of course :-). Fire up your favourite editor and point it at ~/.config/uzbl/config . Then, make sure you have an entry like this: @on_event NEW_WINDOW event NEW_TAB %s Now, any request to open a new window actually ge...

Occasionally, after committing some changes on a bzr branch, I'll come back to it and want to make further changes. So, I'll have done something like this: $ bzr commit $ # Oops! Forgot to update foo.c. Let's do that now... $ vim src/foo.c $ bzr status modified: src/foo.c But rather than creating a second commit for the newest changes, I'll want to combine those new changes and the changes in the latest commit into a single new commit. How do we do this? With bzr its easy: $ bzr log -l1 > /tmp/commit.log # save the latest commit log entry $ bzr shelve --all -m "latest changes" # save the latest uncommitted changes $ bzr uncommit --dry-run # check its going to work $ bzr uncommit # undo the last commit $ bzr unshelve --dry-run # check if its going to work $ bzr unshelve # apply the latest changes to the working directory $ bzr commit ...

Occasionally, when you're exploring the truly vast range of offerings in the Ubuntu Software Archives via the wonderful Ubuntu Software Centre (or maybe via " apt-cache search "), you might find a graphical application that doesn't have an icon. If this happens, there are 2 things to do: Raise a bug on that application to have an icon added. Add an icon temporarily. Raising a bug is easy, just type: $ ubuntu-bug <thing> Where " <thing> " is either the name of the program you are running, or the package that program lives in. However, you can also quickly add an icon yourself using this simple technique... There are 2 steps: Select your icon Create a "desktop" file Icons are installed in the "/usr/share/icons/" directory by default, so have a browse around to see what you like. If you're still struggling to find an appropriate icon, you could add the package wm-icons which adds over 1500 new ones (!): ...

If you run any chroot environments such as schroot, they will generally set your prompt as a reminder that you are actually running within a chroot. For example with schroot, I have: $ schroot -c oneiric (oneiric):~$ echo hello hello (oneiric):~$ exit $ When you're in the chroot, you get the chroot name prepended to the prompt (here " (oneiric) "). But if you play tricks with your prompt variables ( PS1 , PS2 , etc) using maybe the magic bash PROMPT_COMMAND variable, you need to take care. I use screen , tmux , or byobu so need to take twice the amount of care since: I modify my prompt quite extensively I only have 1 window which multiplexes all my terminals (it's easier to make a mistake :) The problem is that if you forget which window you're in, you may end up modifying the wrong environment - installing packages in a minimal chroot rather than in your main (non-chroot) environment, or maybe trashing your live system rather than a throw-away chroot...

This is a useful trick to avoid creating lots of intermediate temporary files when you're trying to compare two files that are almost the same, but which have some fields which are guaranteed to be different. Classic examples of this are two log files that have almost the same data in them, but where every line in these files is prefixed by a pesky timestamp which is different between the two files. bash process substitution (using named pipes) to the rescue! Let's assume we have two files " file1.log " and " file2.log " and the first six space-separated fields comprise a timestamp. To ignore those fields and just diff the log file contents we can do this: $ diff <(cut -d" " -f7- /tmp/file1.log) <(cut -d" " -f7- /tmp/file2.log) But why limit yourself to a textual diff. Go graphical if you prefer: $ meld <(cut -d" " -f7- /tmp/file1.log) <(cut -d" " -f7- /tmp/file2.log) This technique can be employed ...

How do you run multiple commands in bash and calculate the total time taken to run all the commands? Use a list by surrounding the commands with curly braces: time { sleep 2; uptime; true && date; } The tricky bit is remembering to add that last semi-colon - without it, the command will fail to be parsed by bash. Also, the spaces either side of the curly braces are mandatory.

Amazing how many people don't know this skool technique to reset a corrupted terminal: ^jstty sane^j Note - you don't press return/enter at all and those are CONTROL+j combos at either end.