#ifdef linux

Introduction In these heady times of almost daily advances in UI pizzazz, you could be forgiven for thinking the terminal is somewhat of a dead-zone when it comes to excitement. Oh how wrong you would be though...! If you've never used  Byobu ,  Dustin's  awesome text-based window manage, sudo apt-get install it without delay to be bathed in pure terminal goodness. As shown below, byobu comes with a whole host of standard indicators, allowing the display of useful snippets of information. The indicators are minimal out of terminal-width real estate necessity, but that's also their strength - they provide just the details you really care about in a tight ASCII format. And they're cute of course :-) However, byobu has a well-kept secret: when running with the tmux backend, it supports Unicode indicators. So with the proviso that you are running " byobu-tmux " rather than " byobu-screen ", you can squeeze down those indicators even further...

Quiz How many attributes of a processes "environment" can you think of besides its environment variables? I'm using the term "environment" in a very loose sense here to mean "any system or process level attribute that can be queried via system calls or library calls (or " /proc -picking ") that affects a running process". I'm also including details of the process itself and details of the program that came to be a running process. We're not talking about installed packages or application configuration files in /etc here, but purely low-level program, process and system meta-data. I've got over 20 items in my list excluding environment variables. Whilst you're pondering on that... Compare and Contrast If you've been involved with computers for any appreciable length of time, chances are you have come across the scenario where some program fails to run in a particular environment, but works "perfectly...

My output utility (originally called ' out ' - see previous post ) is now available in debian sid as ' utfout ': http://packages.debian.org/sid/utfout

Have you ever wanted to download a Debian  package from an Ubuntu system? Well you are not alone: hidden away in the wonderful " ubuntu-dev-tools " package is the tool for you - the excellent pull-debian-source , written by  tumbleweed . This is a really useful tool which is also fast ! $ sudo apt-get install -y ubuntu-dev-tools $ pull-debian-source hello pull-debian-source: Downloading hello version 2.8-1 pull-debian-source: Downloading hello_2.8.orig.tar.gz from ftp.debian.org (0.665 MiB) pull-debian-source: Downloading hello_2.8-1.debian.tar.gz from ftp.debian.org (0.006 MiB) dpkg-source: info: extracting hello in hello-2.8 dpkg-source: info: unpacking hello_2.8.orig.tar.gz dpkg-source: info: unpacking hello_2.8-1.debian.tar.gz Or, to download the at package from the sid release: $ pull-debian-source at sid pull-debian-source: Downloading at version 3.1.13-1 pull-debian-source: Downloading at_3.1.13.orig.tar.gz from ftp.debian.org (0.117 MiB...

One particularly useful piece of information I've been wanting to add to the Upstart Cookbook for a while now is the upstart-events(7) manual page. This page shows a summary of the "well-known" Upstart events that are provided on an Ubuntu system.  However, as show in the link, formatting this data is tricky due to the number and complexity of the tables. I wondered about converting the troff source to some other format (maybe DocBook) and using that source to generate both the man page and the same data in a format suitable for inclusion in the Upstart Cookbook. However, DocBook seemed a bit heavy weight and I'm not convinced it could handle it (tell me if I'm wrong!) My preference actually is to keep the source as troff since: troff+tbl is a very rich language which provides a lot of control. I want full control over the width of the tables The man page may look a little "cramped". I could have padded it out and made it a little easier ...

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.