Linux command line basics for beginners: Part 3
Here's another installment of the Linux CLI basics series. This time we will deal with other interest-worthy tasks, like setting up your keyboard layout or using utilities to find files on your drive(s). We hope that the series will help you become a keyboard/terminal guru.
1. The tasks, part three
1.1. Setting the keyboard layout
When you're using some fancy desktop environment, changing the layout of your keyboard is simple and easy. A few clicks, you choose your preferred layout and maybe other localization settings and that's that. But what if you find yourself at a command-line-only machine and you have to use the machine, but the layout is set to French? The keys show a symbol but you type another and nothing works as it should. What to do? Or you decided to dump bloated GNOME or KDE for some lightweight window manager like Fluxbox. What you should use for this task strictly depends on whether you have X installed or not. If you do, the utility is called setxkbmap. If you don't you can use various tools provided by your distro (by the way, remember that we are using Ubuntu for our examples), but we will show you how to do it in terminal-only mode without depending on some distro-specific tools.
The first method shown will be the one that assumes that you have X.org installed and you're using it in conjunction with some WM, but you don't have any specific GUI tools for layout changes. As always, I recommend you take a few minutes to look over the setxkbmap manual page to get an idea of the options and general usage flags. As you can imply, the utility's name stands for "set X keyboard map". I remember using shell scripts that contained only the setxkbmap lines needed and then setting up keyboard shortcuts that invoked said scripts as needed (~/.fluxbox/keys): maybe this is a trick you will use after reading this article so that your work will become easier. That's the charm of Linux, there are virtually no limits on what you can do with it.
Enough talk, let's see some practical examples. If I have the US English layout set as default, which happens in most cases, and I want to change it to French, all I have to do is
$ setxkbmap -layout fr
I dare you to execute this command, even though you don't need a French layout, and then try to get back to the US layout. The layout name is 'us', by the way, but that is hardly the point. Now, a logical question would be "how do I know the names of every layout I might wanna use?" Very simple. Just take advantage of the power of ls and your shell, by doing
$ ls /usr/share/keymaps/YOUR_ARCH/*
The rule of thumb is that whatever name comes before the kmap.gz suffix is the name of the layout to use with setxkbmap, ignoring the include directory which is of no interest to us. YOUR_ARCH is your architecture, which usually will be i386, although the system is a 64-bit machine/OS combo. Another important flag to setxkbmap is -variant, because many layouts have different variants, "different" being the keyword. One language doesn't mean one layout, and one layout doesn't by any means mean one variant. The language->layout relationship is a social/hystorical/political one (going further with the French language, France once had lots of colonies that in the end inherited the language, with certain specific aspects. The layout->variant has to do with certain hardware. For example, Macs or Sun boxes have keys a PC doesn't, and the keys are laid out differently. ) So if you need non-PC layouts, eliminate 'i386' from the ls command above. This is a distro-agnostic, X-centric way to set up your keyboard locale. What follows is the Debian/Ubuntu way.
dpkg-reconfigure is a tool that every Debian admin uses and loves. One can configure many facets of the systems using it. A good note before we go further would be that these commands you are about to see change the keyboard layout settings permanently, as in they survive between reboots. Also, they are not set per-user, but system-wide. Here goes:
# dpkg-reconfigure keyboard-configuration
Many popular, desktop-oriented distros have similar tools, like Fedora's system-config-* tools or yast* for OpenSUSE. If you're at a non-X terminal, the loadkeys command is what you need, and the argument to loadkeys is exactly the keymap file, with the full path, as described below, but keep in mind that it won't work with an X terminal like xterm or konsole. The French example is
# loadkeys /usr/share/keymaps/i386/azerty/fr-latin1.map.gz
It's strongly recommended you read the manual of loadkeys, because using the command may affect other users, even after you logged out. You have been warned. Also, keep in mind that every Unix system has its' own specific ways of doing this kind of work, so don't expect to use these commands on OpenBSD or Solaris and get the expected results, if any.
1.2. Finding files
As an example, KDE has a system of finding files by creating a database of the file system contents and updating it constantly, for faster later searches. This sounds great, except it only works on KDE and it's a resource hog. You can do all the indexing/searching stuff from the command line, and this will work on all Linux systems, with all DEs, and even on BSD, which offers the stuff needed as part of the base system. Solaris users can install findutils.
There are two approaches to this: the database one and the database-less. There are advantages on every side, of course: when creating a DB first, subsequent searches will be way faster, but one has to make sure the DB is up to date. Many Linux distributions install a script that runs daily or weekly to make sure your database is fresh, but you can always use the specific tools for this, namely cron. You can go the other way, and thusly you'll have actual filesystem info all the time, but the process will be slower, especially if you have large or even remote disks, like NFS mounts.
The database-using tools are called locate and its' friends, mlocate and slocate, but using locate, which might be a symlink to *locate on some systems, is enough. As before, only basic usage will be presented, and for the rest, there's the manual page. Because it uses a database, you don't have to tell it where to look or change the current directory. Just use
$ locate PATTERN
For special characters and advanced usage, again, use the manual page. But before you do all the locating, how do you create the database? The command is updatedb (update database), and that's all you have to do. It will take a while, like I said, depending on speed disk/interface/size, but after that you can use locate for speedy searches.
whereis, which and apropos are commands that belong in this section, although they do specialized searches, namely files in PATH and/or MANPATH. These two are very important environment variables that tell the system where to find files you need when typing at the command line (PATH) or manual pages (MANPATH). For example, if you'd type 'ls' in your terminal but the directory where ls is located (/bin) is not in PATH, you'd get "command not found" from the shell.
$ whereis ls
So whereis and which help you find files in PATH, useful when you need to know the location of an executable, for example, and apropos helps you search for manual pages, but you can also use -k as a flag to the man command. What the differences between whereis and which are ... that's something for you to find, so you will know where one or another will suit your needs better. The manual pages are also indexed in a database, usually refreshed periodically with cron. I found myself talking without a working example, so here's how to find something in /usr that matches a pattern:
$ find /usr -name \*pattern\* -print
The asterisks are used just as you use them with the shell or other software that supports wildcards, and they are escaped (with the backslashes) because we want them to be interpreted as such by find, not by the shell. So the syntax is 'find $location $pattern $options', but find can do a lot more, as long as you know its' powers. So...well, you know, and I repeated myself already.
Depending on your feedback, we might publish a part four of this series.