How to modify basic system settings with dpkg-reconfigure

You have probably been told at some point to dpkg-reconfigure a package. This command belongs to the debconf infrastructure and what it does is execute the package's configuration script. The script usually recreates data or configuration files belonging to the package, and it may ask you a few questions in the process. Reconfiguring packages is one way of configuring and customizing your installation besides editing configuration files directly, or using GUI tools like KDE systemsettings or GConf.

To get a nice formatted list of installed packages that can be configured, do

cd /var/lib/dpkg/info/ && ls *config | sed 's/\.config$//'

Here are the most useful of them, and what configuring them does.

apt-listchanges: This package is likely not preinstalled on your distribution but useful for displaying changelogs when upgrading your system. Configuring this package asks you how it should output the package changelogs (inline in apt's output, or in one of several viewers), whether and where to send mail notifications, as well as some other settings.

ca-certificates: Asks whether to trust new CA certificates, and presents you a list where you can select which certificate owners to trust. You probably will not want to change anything here.

console-data: Lets you select a keyboard map to use on the console.

console-setup: Lets you select a character set and font for the console. This comes in handy if the console does not display some extended characters, or the predefined font is a 512 glyph font (like Terminus) that prevents the console from using the full color palette.

debconf: Lets you select the desired frontend for debconf and how many questions you want to be asked when running dpkg-reconfigure. You probably want to select the dialog frontend which is easy to use and can run on a plain console.

fontconfig-config: Allows you to configure X font hinting, subpixel rendering and whether you prefer pretty outline or ugly bitmap fonts.

keyboard-configuration: Lets you select model and language of the keyboard, what to use as Alt Gr and Compose, and whether the X server can be terminated using Ctrl-Alt-Backspace.

libpaper1: Sets the system-wide standard paper size (default: A4).

linux-sound-base: Asks which sound system should be used by default (ALSA or OSS).

locales: Asks which locales should be supported on your system, then generates these locales. Unselecting locales you will not use results in a few less megabytes of wasted storage space.

man-db: Asks you whether to use preformatted manpages, then updates the manual database.

popularity-contest: Asks you whether to participate in the Debian package popularity contest. Anonymous package statistics are sent once a week so the Debian project can decide which packages are popular enough to be included in the main distribution.

resolvconf: Asks you whether /etc/resolv.conf should be updated dynamically, which is likely what you want if you get the DNS servers via DHCP.

tzdata: Lets you select your time zone.

x11-common: Sets who is allowed to start the X server. The default "console users only" is fine and not too insecure.

Build a secure home network using SSH

This Howto explains how to build a local network where communication between machines takes place over the Secure Shell Protocol. This is not only more secure (especially over wireless) but also enables you to conveniently get a remote shell on every machine.

I'm assuming the machines are connected to each other via a dedicated hardware router, but network topology does not really matter as long as all machines can see each other. Also I'm assuming all machines are on the same network segment, i.e. you have a typical small-scale home network.

First, install the ssh metapackage on the machines you want to connect. On Debian based systems, this will get the OpenSSH client, the OpenSSH server and the blacklist of insecure keys. All are required for the setup to function properly.

Next, we will add some basic network security. On the machines you want to connect make sure that /etc/hosts.deny contains the line

ALL: ALL

This blocks all inetd controlled services (most stuff except HTTP and Samba) coming from all hosts by default. In /etc/hosts.allow add:

ALL: LOCAL

This allows all services running on your local network (i.e. all hosts whose names don't contain a dot) to access the local host.

If you are paranoid and only want to allow ssh, instead use

sshd: LOCAL

You will likely not be running a DNS server on your network, so you will have to set the hostnames on each machine. The top of each /etc/hosts file should contain something like

127.0.0.1 localhost
127.0.0.1 nameofthismachine

Where nameofthismachine is the desired hostname for the local computer. In the same file, add the IP addresses and hostnames of all other machines that machine should be able to connect to, for example

192.168.0.2 anothermachine
192.168.0.3 yetanothermachine

You can find out the network IP address of a box either by running ifconfig on that machine or logging into the router and looking at the logs.

Changes to the hosts* files should come into effect immediately, but the router may be slow to pick up hostname changes, so it is a good idea to power cycle it now to renew the DHCP leases and update the routing table.

Now, at one of the boxes, try

ssh username@someotherbox

and if ssh can connect to someotherbox, you are asked for username's login password. Now you can work with that shell like you were sitting in front of the other computer. You can also start GUI programs when adding the -X switch (which enables X11 forwarding). For better performance but less local security you can add -Y to enable trusted X11 forwarding.

ssh -X -Y username@someotherbox

Then you can start xeyes or some other graphical app for testing. Depending on the processing power of your router and link speed, even watching DVDs over the SSH connection may work well.

Ok, what about transferring files? You have several options here. When working on a shell with Midnight Commander, you can establish a shell connection via the Left/Right menus. In KDE, Dolphin/Konqueror and file dialogs understand the fish:// protocol (example: fish://username@someotherbox). Similarly, you can use ssh:// in many Gnome applications. You can also mount the remote computer's filesystem using sshfs.

If you have a network service running on one of the machines, like a streaming server, you may want to tunnel the data through SSH too. To tunnel port 6666, with the local machine at the receiving end, do

ssh -R 6666:localhost:6666 username@server

Hopefully, this article has helped you secure your network a bit.

Store volatile data in RAM using tmpfs

There are several reasons why you might want to hold certain data in non-permanent memory. Applications that create a lot of temporary data, causing system slowdown and strain on the storage medium, are an example, or you want the data to be gone after every power cycle because it is of no use anymore at that point, or the data would simply eat up too much storage over time.

Unix-like platforms support a file system named tmpfs, which is a RAM filesystem growing and shrinking dynamically with its contents. Setup is straightforward. To mount /tmp as tmpfs, you add the following line to /etc/fstab, after the physical partition mounts:

none /tmp tmpfs defaults 0 0

Be sure to clear out the contents of the old /tmp directory before remounting, because the mount will "overlay" what was previously there and the data will not be accessible but still occupy space.

Other locations that are good candidates for a tmpfs: /var/tmp, /home/username/tmp, /var/cache/apt/archives, web browser and other caches in your home directory. Don't be tempted to put /var/log on a tmpfs because the logs are important information sources for troubleshooting and forensics. Use logrotate instead for limiting the amount of log storage.

When you are done setting up the temporary file systems, issue a mount -a to remount everything from fstab.

GUI vs. CLI: Apples vs. oranges

I have never managed to wrap my mind around the tired old GUI (graphical user interface) vs. CLI (command line interface) debate and which is "better", and why you should try to avoid or strictly stick to the one or the other.

It is like comparing a brush and a hammer. Both are tools, but for different purposes, and if you want to be prepared for a wide variety of home improvement tasks, you better have both in your tool chest and a basic understanding of how to use them.

If you are good at building furniture but suck at painting, you call a friend who glazes your table for you, or you practice on a piece of leftover wood. Your friend may be a good painter with a steady hand and a great sense for color but completely clueless on how to fix a broken door hinge. But with only a little bit of learning and practice, he could become proficient enough to do small repairs himself.

Along the same lines, life can be easier if you have a basic understanding of both the GUI and CLI environments available on your computing platform, because each is included for the purpose of helping you with specific tasks.

GUIs shine when it comes to interactive workflow, especially editing on-screen data, like an image or a spreadsheet. Essentially, complex spreadsheets and desktop publishing were the applications that made graphical interfaces necessary in the first place. Navigation within the environment is highly interactive too; you activate menus or buttons, working your way to the target. A lot of information can be presented on the screen at once, which is great for working with multiple applications or pieces of data at the same time.

CLIs allow calling commands or starting applications with a few keystrokes and also have built-in scripting mechanisms which allow for building heavily customized command pipes and conditional/repeated execution. The vast majority of processing is done non-interactively (you only have the "upfront cost" of constructing a suitable textual expression). Navigating the environment is a minor matter; you change directly into a directory if you really need to be there, but commands are callable regardless of your location within the directory tree. Sophisticated means of auto completion and history search are available via simple key combinations, so you don't have to type any more than absolutely necessary.

It can be said that CLIs are designed to spare you time with generic tasks that do not need to be interactive, while GUIs are designed as an efficient way to do interactive document centric tasks. You should use a CLI for: Capitalizing text that has to fit some specific pattern, in some files scattered randomly over several partitions, and the filenames and file modification times have to fit a specific pattern too. That's a sed one-liner in a Unix shell and will waste hours when done in a GUI. You should use a GUI for: Adding some nice gradient borders to an object group in a SVG graphic, and make a text element run along it. Requires high-level wizardry in a CLI, better done in five minutes in Inkscape.

You should be able to see now that both user interfaces are highly efficient and mature solutions for getting different sets of tasks done. What you will end up using depends on what you want to accomplish, and use of an unsuitable interface will likely cause frustration and an "it can't be done" feeling. Call a knowledgeable friend then, or better, spend some time getting accustomed to the more suitable tool.

How to generate PHP code from Bash

If you are into server side web programming, you will probably have had some exposure to PHP. Advantages of the language are that it is very widely supported, and that it can be freely mixed with HTML within the same file.

You might want to have some script running on the server for the purpose of generating PHP code. Unfortunately, you cannot throw everything at Bash's string functions as-is because some special characters are used to denote expansion or redirection. One totally unexciting but have-to-know bash feature comes into play here, called quoting.

Quoting is the art of using single or double quotes or backslashes to protect a range of characters in a string from being interpreted by Bash. In short, single quotes protect everything inbetween them so the input is taken 1:1, double quotes allow variable expansion (via $dollar sign) and command substition (via `backticks`) and protect mostly everything else, and the backslash protects the character following it. Mixed or nested quoting is often necessary and one of the most unintuitive things on earth, but for this howto, I will keep it as simple as possible.

Ok, let's do a "Hello World" in PHP, via Bash.

echo -e "<?php\n  echo \"Hello World\";\n?>"

Output:

<?php
  echo "Hello World";
?>

Why do I use the -e parameter? It allows the echo command to interpret C-style backslash escape sequences (like \n for a newline, \t for a tab). In addition, I'm enclosing the whole string in double quotes, as this allows for interpreting shell variables and escapes without messing up on most other stuff. The \n after the opening PHP tag is a line break, then two spaces follow for intendation. I have to escape the double quotes around "Hello World" ("protect" them) to not have them interpreted as string quoting, and output them literally instead. After that comes the semicolon that ends the PHP command, another newline and the closing PHP tag.

But, you might complain now, the PHP code itself might contain backslash quotes too! How to escape that, dude? Well, in that case we protect the backslash by writing a double backslash.

echo -e "<?php\n  echo \"Hello \\\"World\\\"\";\n?>"

Output:

<?php
  echo "Hello \"World\"";
?>

The parts with three backslashes in a row are a backslash protecting a backslash, followed by a backslash protecting a double quote.

Because of the "weak" double quoting, we can use shell variables and command substitution.

echo -e "<?php\n  echo \"Script generated by $SHELL\";\n?>"

Output:

<?php
  echo "Script generated by /bin/bash";
?>

<?php\n  echo \"Script generated by $SHELL on `uname`\";\n?>"

Output:

<?php
  echo "Script generated by /bin/bash on Linux";
?>

You can build on this from this point on: Just keep in mind that quoting with double quotes protects all characters except ", \, $, and `, so you have to escape them with a backslash if you want to output them literally.

Howto: Plasmoid that shows your online Kopete contacts

Together with Pidgin, Kopete is certainly one of the top choices for a multi-protocol messenger in a Linux environment. Although it doesn't support all of the (usually rather annoying) extra features of some protocols, it allows me to keep in touch with my family and fellows without having to install three different chat applications. What sort of bugs me is the currently missing IRC support, besides of that it does everything I need it to and integrates well with other KDE based software.

Now what if I want to start a chat quickly without opening the contact list, you might have asked yourself? Well, you are not out of luck. What you need to do is install an additional plasmoid that contains a few detachable widgets. It is called Lancelot and can be obtained by installing kdeplasma-addons.

Unlock the widgets if necessary by right clicking on the desktop, then right click again and choose "add widgets" (I'm using German KDE, so it might read differently in the English localization). Select the Lancelot launcher (not the component) and drag it to some free space on your desktop or the panel.

That's a nice menu, isn't it? The best thing about it is that you can drag the title of a section and tear off a copy, which can then be placed anywhere as an independent plasmoid. Tear off the contacts section and place it on the desktop or in the panel, and you have a nice widget that displays your online contacts and allows for starting a conversation with a click, or by just hovering the mouse over the right hand arrow (that no-click behavior can also be switched off if it sucks for you). You can remove the Lancelot launcher afterwards if you don't need it anymore.

Gmail works with Konqueror now! Sort of

Konqueror's KHTML rendering engine is known to not be really full-featured when it comes to full-blown web applications like Google Docs, Gmail, iGoogle and Zoho. Of course I have kpart-webkit installed so I can toggle engines on the fly, but it is just buggy in a different way, so it doesn't work with these apps either. Arora works fine but is in an early stage of development and crashes regularly, also it doesn't integrate as well in KDE as I would like.

While I have no means of getting a full web experience with a KDE based browser, I got Gmail running flawlessly on Konqueror. It seems Google has updated some of the code to make it more cross-browser compliant. However, you will still get the "unsupported browser" warning and a hell of quirks when visiting Gmail and going to your inbox. That is, until you forge the user agent to identify as Firefox 3.0.5 (other versions or browsers will not work, it has to be that one). Gmail works as intended then, including advanced functions like creating filters. In Konqueror's settings, you can specify to always use that user agent on mail.google.com.

How to rip DVDs to Theora

It came to my attention lately that K9Copy has evolved from a pure DVD transcoder to a remarkably full-featured video backup solution. Thus, I decided to rip my newly-bought 7 DVD Asterix collection to disk. But ... by Toutatis! It supports both ffmpeg and mencoder as a backend, but none would let me rip to Theora with Vorbis audio. I decided to rip to hard disk without encoding first, then work from there.

The "rip without encoding" feature in K9Copy stores the selected video and audio streams in a .mpg file which can be fed into a transcoder without further steps. I played around with ffmpeg a bit, but it seems to contain several Ogg related codecs which require fine tuning until you get a good result. After searching the web, I found the super easy solution: ffmpeg2theora. It's a small wrapper around ffmpeg that takes an input file, writes to an output file or stdout and provides a few speed/quality related options.

In the most simple case, if you want to convert some small clip or such, you would just do ffmpeg2theora infile and it would trancode to infile.ogv. For DVD material I recommend overriding a few defaults. Good quality seems to be achieved by calling it this way: ffmpeg2theora -v 6 -c 2 -a 5 --optimize infile.mpg. This sets above-average video quality (6, default is 5), downmixes the source audio to two channels if necessary, sets audio quality to 5 (CD quality) and enables a few file size optimizations.

Here are the steps in detail:

• Start the K9Copy Assistant.
• Select your DVD drive as the backup source.
• As the backup target, select "rip without encoding" and specify an output file.
• Unselect all titles except the main movie; use the video preview if you are unsure what title to select.
• Select the desired audio streams and subtitles; usually you will only want to keep the primary audio stream of the desired language.
• Unselect "change shrink factor" if it is selected.
• When K9Copy is done ripping, open a terminal in the directory with the ripped file and do ffmpeg2theora -v 6 -c 2 -a 5 --optimize yourrippedfile.mpg

More fun with X keymaps - dead keys

I already demonstrated lately how to input nice typographic characters using Alt Gr, but depending on your keyboard layout there are more possibilities of producing more or less useful glyphs using combined keystrokes.

You may know that certain keys on your keyboard are dead keys, which create a diacritical character when followed by a letter key, or themselves when pressed twice or followed by a space.

It's nice to be able to type foreign words like ingénue, and I found out that in the X Window System, you can combine the circumflex with other diacritics to produce a double diacritical character, for example ^`a yields ầ. I'm missing a trema dead key on my German keyboard because it provides umlauts directly, and I could only modify ö - ~ö yields ṏ. Still trying to figure out how to type Dutch y with trema, however.

Apart of discovering obscure glyph hacks, I found something of actual use: Circumflex plus number/math operator allows you to type mathematical superscripts. Hence, together with the knowledge of Alt Gr keymaps from my other article, you are now able to correctly denote the proton mass as 1.672621637 × 10⁻²⁷ kg without pasting symbols from an unicode table.

Boot Debian faster with Upstart

The Upstart daemon has been in development for quite some time as a contemporary replacement for the classical System V init. Being fully backwards compatible with existing init scripts, Upstart introduces support for event based, parallel execution of startup tasks in the form of "jobs" stored in the /etc/init directory.

Looking at the job scripts, I see it doesn't do much more so far than entering the default runlevel and executing the legacy System V scripts, but a speedup just before the graphical login is already achieved by allocating only one virtual console by default. Also, there seems to be less of a delay directly after the kernel is done initializing. I didn't notice any issues after having used Upstart for a month now, so I'll tell you how to install it on Debian Sid. Upstart is also available in some other Debian based distros and Fedora, use the respective package manager there. I'm using Aptitude for this article.

If Aptitude isn't installed on your system, get it using your GUI software manager or do a sudo apt-get install aptitude, then start it. Use / (the slash) to search for the upstart package, then press + (plus) to mark it for installation. Now aptitude will complain about a conflict with the sysvinit package; that's because upstart wants to remove sysvinit, but sysvinit is an essential system package. Ignore that, search for sysvinit and mark it for removal using - (minus). Aptitude will ask you to confirm the removal by inputting the phrase "Yes, I am aware this is a very bad idea". Do that and the conflict will resolve. Press G and verify in the shown summary whether sysvinit will really be removed (shown in purple) and upstart will really be installed (shown in green). If you screwed something up, press q and undo the selections, else press g another time to start the installation. When done, you can quit Aptitude by pressing q in the main view. Next reboot will be slightly faster :-)

Can we have more Qt apps please?

Managing software has been sort of a hassle for me lately, as I like to keep my package base free of cross-desktop dependencies. More precisely, it has become harder to find GUI software outside of the KDE application suite that doesn't depend on Gtk.

I suspect a number of reasons is responsible for this. Ubuntu, the most popular starter distribution, uses Gnome as its default desktop, and its KDE variant permanently lags two releases behind. Gnome is also backed by GNU and Red Hat. That doesn't change the fact that Gtk is rarely updated and still lacks in functionality for me as much as it did years ago.

I plainly hate the file dialog. Sorry, there is no way I could say it politely. It is the antithesis of "having useful features". It lets me double click on folders and files (I'm used to single click), it has a vanilla file name input box, a non-obvious "select-as-you-type" feature and a half-baked location sidebar. I can't do any file operations in the dialog, or fine-tune the view. It doesn't remember its size and position. That dialog nearly makes me understand why fanboys from other platforms like to compare Linux desktops to early releases of their preferred operating system.

That doesn't mean I dislike Gnome as a desktop. It is trying hard to be an easy to understand environment without excess complexity, which isn't a bad idea when coping with non-geek users. What bugs me is the ancient GUI toolkit sitting on it. I could go and explain that to the Gnome developers like others did, but they will just flame me for not following their ideals.

If you use Gnome, it doesn't mean you can't use Qt for software development. Despite the fact that it is used by KDE as part of its application framework, it is an independent product and tries to integrate into any desktop environment as seamlessly as possible. That cannot be said of Gtk. It misbehaves (not adhering to desktop settings) and looks non-native in both KDE and Windows.

You also get not only a GUI toolkit with Qt, but a complete cross-platform application development framework plus a powerful IDE. If you don't feel comfortable with your current framework or IDE, you might want to have a look.

For the sake of fairness, my next opinion post will be critical of KDE. It is my preferred desktop and has its share of problems too.

Make commands behave nicely by default, using shell aliases

You have surely been in situations where a command needed an unwieldy parameter list to do things in a specific way, and editing a config or parameter file, or creating a shell script for the task, was not an option. I already wrote an article on how to search your command history, but in many cases you will not be executing the command interactively; it will be called from a script or such. Well, you are not out of luck. Let me show you one nice trait of bash aliases.

Your .bashrc might contain something like this:

alias ls='ls --color=auto'

This line defines an alias for the ls command, named ls. Weird? Not at all. Aliases override commands and builtins of the same name. The above example results in ls always displaying colorful directory listings, because Bash checks whether a word is an alias before looking for a builtin or command.

Another example: If you frequently ssh into boxes on your local network and start GUI programs on them, the following enables X forwarding by default.

alias ssh='ssh -X'

Aliases also work for programs that are started from the menu in a desktop environment. If you are over 25 and happen to like classical console games, meaning you probably have ZSNES installed, you can fix issues with missing audio using

alias zsnes='zsnes -ad sdl'

Add that to .bashrc, then log out and in and clicky-clicky on the icon.

The hidden powers of Alt Gr

If you are using a non-US or a US-International keyboard, you will probably be aware that the Alt Gr key allows for input of certain foreign characters and symbols, which are also printed on the keyboard. In case you are on a *nix box running the X Window System, you have easy access to a lot more characters; in fact most keymaps contain a full Alt Gr and Alt Gr+Shift mapping.

Most interesting for general purposes are the number row and the bottom alphanumeric row, as these contain additional symbols and punctuation that you might want to use for an improved text appearance. For this post, I checked out several common keyboard layouts (German, US international, UK, Canadian, Spanish and French) and tried to find commonalities.

With the exception of US and Canadian, you get native typographic quotation marks with V and B (hold Shift too for single marks). German and Spanish give you French quotation marks on Y/X respectively Z/X. German has long dash and ellipses on the bottom row. C yields the copyright symbol on all keymaps. On the number row you can access proper fractions (at least if you are not Canadian) and some more with Shift. On 8, shifted, you have the trademark sign (with the exception of US and Canada). The bottom row, shifted, also provides multiplication and division signs on most keymaps.

So, the next time you need mathematical symbols or advanced punctuation, you don't always have to copy and paste from a character set viewer, possibly it's already right there on your keyboard.

ARM netbooks still not hitting store shelves

If you knew me quite well (but you don't, as I started this blog ... well, yesterday), you knew I would sell my soul for one of these. I have been desktop free for ca. two years now because upgrading the box resulted in a 23% increase of power bill with me basically doing the same internet, programming and graphics editing work as before, at exactly the same speed.

My current primary workstation is an Asus EEE 701, upgraded to 2 GB of RAM, hooked up to a 19" widescreen monitor and a bunch of peripherals attached via a 13-port active USB hub. As I found out by measurements, the netbook draws about 12-16 watts under normal interactive workload and about 22 watts when the integrated Intel graphics have to do 3D. I verified the battery runtime to be about 3½ hours, including some gaming and some WLAN use. Arch + KDE 4 + desktop effects are really speedy on it.

Thus, I learned to love netbooks as reliable universal gadgets at an irresistible price point. Then Windows was dumped upon the market for free, and netbooks became slightly shrunken laptops at a price point that would make you rather choose the full-size laptop. Voíla, more Vista sales for Microsoft, Linux killed off, netbooks killed off, mission accomplished.

Today I realize netbooks were not just a random trend out of nowhere. Linux had been taking off large scale in embedded years before as a means of keeping microprocessor costs low. Software license costs are obviously an issue if your electronic goods sell for somewhere between 0.10€ and 10€ per unit. Also, smartphones had become more powerful and full-featured but still suffered from small screens and limited methods of user input. Netbooks basically emerged as the missing link between high-end embedded and low-end non-embedded.

When they came out, I immediately bought one because it was the first time I saw preinstalled Linux on a store shelf, but foremost because I knew they wouldn't be available forever, being vulnerable because of them being x86 based. They were (sort of) capable of running desktop Windows; more precisely I heard reports that it felt like wading through tar on the first-generation netbooks which had been designed with Linux + simple everyday tasks in mind. Which was nothing a good portion of lobbying and vendor strong-arming couldn't fix. After everybody was convinced that a netbook's primary purpose consists of playing egoshooters, running Photoshop on a 7" screen and spending 600€ for an additional Microsoft Office license, Vista laptops finally started selling.

Various more or lesser known OEMs have since tried to fill the gap from the other side using ARM based netbooks. Linux runs as fine on ARM as it does on x86. Microsoft can only counter on this architecture using their unpopular Windows CE offering. They can't exert pressure via the software platform, as CE is a completely different kernel from desktop Windows and doesn't have the amount of software or extended hardware support Linux offers.

On the hardware side you can expect 8 hours of runtime when not plugged in, and ARM licensees can sell CPUs cheaply because they produce approximately 1 billion of them a quarter. You get a 150€ netbook that is on par with a 349€ Atom netbook, with half the power consumption.

Yet we see ARM netbooks being announced all the time, showcased, everybody is excited, then they disappear before hitting sales channels. Something nasty might be going on behind the scenes, I suspect. I'm very sorry that my money can't find its way into an ARM OEM's pocket; a quadcore Cortex-A8 as a mobile workstation would surely make me nerdgasm.

Quick & dirty intro to Bash history search

So you typed that loooong incredibly useful command a week ago and no amount of pressing the Up key will unearth it, or you just want to save a few keystrokes on a command you use regularly? Let me introduce you to Bash's builtin history search, a feature that tends to be underused and only partly understood.

There are two ways for quickly searching the history: Incremental search and plain string search. The good thing about both is that you only need to know part of the command you typed, in most cases three or four consecutive letters are enough.

Ok. Let's say you are SSHing into your other box regularly using the command ssh mylogin@myotherbox. Open a terminal and hit CTRL-R. The prompt changes to say "reverse-i-search". Start typing what you search for. Chances are that as soon as you have typed "s" and another "s", it will fill in the ssh command for logging into myotherbox. Hit Enter and it executes the command. If you don't want to, cancel the reverse i-search with CTRL-G. Whatever you started typing before the search will still be there, nice!

If you had happened to ssh into other boxes and didn't get the right result, you can press CTRL-R several times during the i-search to go to the previous occurence (towards the start of the history), or CTRL-S to search towards the end of the history. Note that CTRL-S is often bound to stopping the terminal, but that can be fixed by issuing stty stop ^Q, which rebinds stopping to CTRL-Q.

Bash also has a plain non-interactive search mode that can be entered using ALT-P, or ALT-N in the unlikely case you want/have to do a forward search. The prompt changes to a simple colon then and you can cancel as always with CTRL-G. Type a few letters and hit Enter. The first match will be filled in at the prompt but will not execute, which is great because you can edit it first this way.

Well, there is also a third very non-interactive way of search: Type a bang (exclamation mark) followed by what you search for. !ssh will likely result in this:

$ !ssh

ssh mylogin@myotherbox

mylogin@myotherbox's password:

Useful for quickly repeating commands you use regularly, although dangerous if you don't exactly know what the bang-search will find and execute.