Switching to the Superuser

I use this as a separator to make my prompt more visually

appealing.

Shows the current working directory. It results in a shorter prompt than %/, as my home directory is shortened from /usr/home/myusername to ~

%b Turns off bold.

Again, this is an extra character I use to separate my prompt from the cursor.

" Ends the prompt string.

With this prompt, I always know who I am and where I am. If I also needed to know what machine I was logged into (useful for remote administration), I could also include %M or %m somewhere within the prompt string.

The superuser's .cshrc file (in /root, the superuser's home directory) has an identical prompt string. This is very fortunate, as it reveals something you might not know about the su command, which is used to switch users. Right now I'm logged in as the user dru and my prompt looks like this:

dru@/usr/ports/net/ethereal:

Watch the shell output carefully after I use su to switch to the root user:

dru@/usr/ports/net/ethereal: su Password:

dru@/usr/ports/net/ethereal:

Things seem even more confusing if I use the whoami command:

dru@/usr/ports/net/ethereal: whoami dru

However, the id command doesn't lie:

dru@/usr/ports/net/ethereal: id

uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator)

It turns out that the default invocation of su doesn't actually log you in as the superuser. It simply gives you superuser privileges while retaining your original login shell.

If you really want to log in as the superuser, include the login (-l) switch:

I highly recommend you take some time to experiment with the various formatting sequences and hack a prompt that best meets your needs.

You can add other features, including customized time and date strings and command history numbers [Hack #1], as well as flashing or underlining the prompt.

1.3.2 Setting Shell Variables

Your prompt is an example of a shell variable. There are dozens of other shell variables you can set in .cshrc. My trick for finding the shell variables section in the manpage is:

dru@~: man cshrc /variables described

As the name implies, shell variables affect only the commands that are built into the shell itself. Don't confuse these with environment variables, which affect your entire working environment and every command you invoke.

If you take a look at your ~/.cshrc file, environment variables are the ones written in uppercase and are preceded with the setenv command.

Shell variables are written in lowercase and are preceded with the set command.

You can also enable a shell variable by using the set command at your command prompt. (Use unset to disable it.) Since the variable affects only your current login session and its children, you can experiment with setting and unsetting variables to your heart's content. If you get into trouble, log out of that session and log in again.

If you find a variable you want to keep permanently, add it to your

~/.cshrc file in the section that contains the default set commands. Let's take a look at some of the most useful ones.

If you enjoyed Ctrl-d from [Hack #1], you'll like this even better:

set autolist

Now whenever you use the Tab key and the shell isn't sure what you want, it won't beep at you. Instead, the shell will show you the applicable possibilities. You don't even have to press Ctrl-d first!

The next variable might save you from possible future peril:

set rmstar

I'll test this variable by quickly making a test directory and some files:

dru@~: mkdir test dru@~: cd test

dru@~/test: touch a b c d e

Then, I'll try to remove the files from that test directory:

dru@~/test: rm *

Do you really want to delete all files? [n/y]

Since my prompt tells me what directory I'm in, this trick gives me one last chance to double-check that I really am deleting the files I want to delete.

If you're prone to typos, consider this one:

set correct=all

This is how the shell will respond to typos at the command line:

dru@~: cd /urs/ports

CORRECT>cd /usr/ports (y|n|e|a)?

Pressing y will correct the spelling and execute the command. Pressing n will execute the misspelled command, resulting in an error message. If I press e, I can edit my command (although, in this case, it would be much quicker for the shell to go with its correct spelling). And if I completely panic at the thought of all of these choices, I can always press a to abort and just get my prompt back.

If you like to save keystrokes, try:

set implicitcd

You'll never have to type cd again. Instead, simply type the name of the directory and the shell will assume you want to go there.

< Day Day Up >

Hack 3 Create Shell Bindings

Train your shell to run a command for you whenever you press a mapped key.

Have you ever listened to a Windows power user expound on the joys of hotkeys? Perhaps you yourself have been known to gaze wistfully at the extra buttons found on a Microsoft keyboard. Did you know that it's easy to configure your keyboard to launch your most commonly used applications with a keystroke or two?

One way to do this is with the bindkey command, which is built into the tcsh shell. As the name suggests, this command binds certain actions to certain keys. To see your current mappings, simply type bindkey. The output is several pages long, so I've included only a short sample.

However, you'll recognize some of these shortcuts from [Hack #1].

Standard key bindings

The ^ means hold down your Ctrl key. For example, press Ctrl and then l, and you'll clear your screen more quickly than by typing clear.

Notice that it doesn't matter if you use the uppercase or lowercase letter.

1.4.1 Creating a Binding

One of my favorite shortcuts isn't bound to a key by default:

complete-word-fwd. Before I do the actual binding, I'll first check which keys are available:

dru@~: bindkey | grep undefined

"^G" -> is undefined

"\305" -> is undefined

"\307" -> is undefined

<snip>

Although it is possible to bind keys to numerical escape sequences, I don't find that very convenient. However, I can very easily use that available Ctrl-g. Let's see what happens when I bind it:

dru@~: bindkey "^G" complete-word-fwd

When I typed in that command, I knew something worked because my prompt returned silently. Here's what happens if I now type ls -l /etc/, hold down the Ctrl key, and repeatedly press g:

ls -l /etc/COPYRIGHT ls -l /etc/X11

ls -l /etc/aliases ls -l /etc/amd.map

I now have a quick way of cycling through the files in a directory until I find the exact one I want. Even better, if I know what letter the file starts with, I can specify it. Here I'll cycle through the files that start with a:

Once I've cycled through, the shell will bring me back to the letter a and beep.

If you prefer to cycle backward, starting with words that begin with z instead of a, bind your key to complete-word-back instead.

When you use bindkey, you can bind any command the shell

understands to any understood key binding. Here's my trick to list the commands that tcsh understands:

dru@~ man csh /command is bound

And, of course, use bindkey alone to see the understood key bindings.

If you just want to see the binding for a particular key, specify it. Here's how to see the current binding for Ctrl-g:

dru@~: bindkey "^G"

"^G" -> complete-word-fwd

1.4.2 Specifying Strings

What's really cool is that you're not limited to just the commands found in man csh. The s switch to bindkey allows you to specify any string. I like to bind the lynx web browser to Ctrl-w:

dru@~: bindkey -s "^W" "lynx\n"

I chose w because it reminds me of the World Wide Web. But why did I put \n after the lynx? Because that tells the shell to press Enter for me.

That means by simply pressing Ctrl-w, I have instant access to the Web.

Note that I overwrite the default binding for Ctrl-w. This permits you to make bindings that are more intuitive and useful for your own purposes.

For example, if you never plan on doing whatever ^J does by default, simply bind your desired command to it.

There are many potential key bindings, so scrolling through the output of bindkeys can be tedious. If you only stick with "Ctrl letter" bindings, though, it's easy to view your customizations with the following

command:

dru@~:bindkey | head -n 28

As with all shell modifications, experiment with your bindings first by using bindkey at the command prompt. If you get into real trouble, you can always log out to go back to the defaults. However, if you find some bindings you want to keep, make them permanent by adding your bindkey statements to your .cshrc file. Here is an example:

dru@~: cp ~/.cshrc ~/.cshrc.orig

dru@~: echo 'bindkey "^G" complete-word-fwd' >>

~/.cshrc

Notice that I backed up my original .cshrc file first, just in case my fingers slip on the next part. I then used >> to append the echoed text to the end of .cshrc. If I'd used > instead, it would have replaced my entire .cshrc file with just that one line. I don't recommend testing this on any file you want to keep.

Along those lines, setting:

set noclobber

will prevent the shell from clobbering an existing file if you forget that extra > in your redirector. You'll know you just prevented a nasty accident if you get this error message after trying to redirect output to a file:

< Day Day Up >

Hack 4 Use Terminal and X Bindings

Take advantage of your terminal's capabilities.

It's not just the tcsh shell that is capable of understanding bindings.

Your FreeBSD terminal provides the kbdcontrol command to map commands to your keyboard. Unfortunately, neither NetBSD nor OpenBSD offer this feature. You can, however, remap your keyboard under X, as described later.

1.5.1 Creating Temporary Mappings

Let's start by experimenting with some temporary mappings. The syntax for mapping a command with kbdcontrol is as follows:

kbdcontrol -f number "command "

Table 1-2 lists the possible numbers, each with its associated key combination.

52 Numpad - (Num Lock off)

53 Left arrow (also works in editor)

54 Numpad 5 (without Num Lock)

55 Right arrow

56 Numpad + (without Num Lock)

57 End

58 Down arrow (affects c history)

59 Page Down

60 Ins

61 Del

62 Left GUI key (Windows icon

next to left Ctrl)

63 Right GUI key (Windows icon

next to right Alt)

64 Menu (menu icon next to right

Ctrl)

Those last three key combinations may or may not be present,

depending upon your keyboard. My Logitech keyboard has a key with a Windows icon next to the left Ctrl key; that is the left GUI key.

There's another key with a Windows icon next to my right Alt key; this is the right GUI key. The next key to the right has an icon of a cursor pointing at a square containing lines; that is the Menu key.

Now that we know the possible numbers, let's map lynx to the Menu key:

% kbdcontrol -f 64 "lynx"

Note that the command must be contained within quotes and be in your path. (You could give an absolute path, but there's a nasty limitation coming up soon.)

If I now press the Menu key, lynx is typed to the terminal for me. I just need to press Enter to launch the browser. This may seem a bit tedious at first, but it is actually quite handy. It can save you from inadvertently launching the wrong application if you're anything like me and tend to forget which commands you've mapped to which keys.

Let's see what happens if I modify that original mapping somewhat:

% kbdcontrol -f 64 "lynx www.google.ca"

kbdcontrol: function key string too long (18 > 16)

When doing your own mappings, beware that the command and its arguments can't exceed 16 characters. Other than that, you can pretty well map any command that strikes your fancy.

1.5.2 Shell Bindings Versus Terminal Bindings

Before going any further, I'd like to pause a bit and compare shell-specific bindings, which we saw in [Hack #3], and the terminal-specific bindings we're running across here.

One advantage of using kbdcontrol is that your custom bindings work in any terminal, regardless of the shell you happen to be using. A second advantage is that you can easily map to any key on your keyboard. Shell mappings can be complicated if you want to map them to anything other than "Ctrl letter".

However, the terminal mappings have some restrictions that don't apply to the tcsh mappings. For example, shell mappings don't have a 16 character restriction, allowing for full pathnames. Also, it was relatively easy to ask the shell to press Enter to launch the desired command.

Terminal bindings affect only the current user's terminal. Any other users who are logged in on different terminals are not affected.

However, if the mappings are added to rc.conf (which only the superuser can do), they will affect all terminals. Since bindings are terminal specific, even invoking su won't change the behavior, as the user is still stuck at the same terminal.

1.5.3 More Mapping Caveats

There are some other caveats to consider when choosing which key to map. If you use the tcsh shell and enjoy viewing your history [Hack #1], you'll be disappointed if you remap your up and down arrows. The right and left arrows can also be problematic if you use them for navigation, say, in a text editor. Finally, if you're physically sitting at your FreeBSD system, F1 through F8 are already mapped to virtual terminals and F9 is mapped to your GUI terminal. By default, F10 to F12 are unmapped.

If you start experimenting with mappings and find you're stuck with one you don't like, you can quickly return all of your keys to their default mappings with this command:

% kbdcontrol -F

On the other hand, if you find some new mappings you absolutely can't live without, make them permanent. If you have superuser privileges on a FreeBSD system you physically sit at, you can carefully add the mappings to /etc/rc.conf. Here, I've added two mappings. One maps lynx to the Menu key and the other maps startx to the left GUI key:

keychange="64 lynx"

keychange="62 startx"

Since the superuser will be setting these mappings, the mapped keys will affect all users on that system. If you want to save your own personal mappings, add your specific kbdcontrol commands to the end of your shell configuration file. For example, I've added these to the very end of my ~/.cshrc file, just before the last line which says endif:

% kbdcontrol -f 64 "lynx"

% kbdcontrol -f 62 "startx"

1.5.4 Making Mappings Work with X

This is all extremely handy, but what will happen if you try one of your newly mapped keys from an X Window session? You can press that key all you want, but nothing will happen. You won't even hear the sound of the system bell beeping at you in protest. This is because the X protocol handles all input and output during an X session.

You have a few options if you want to take advantage of keyboard bindings while in an X GUI. One is to read the documentation for your particular window manager. Most of the newer window managers provide a point and click interface to manage keyboard bindings. My favorite alternative is to try the xbindkeys_config application, which is available in the ports collection [Hack #84] :

# cd /usr/ports/x11/xbindkeys_config

# make install clean

This port also requires xbindkeys:

# cd /usr/ports/x11/xbindkeys

# make install clean

Rather than building both ports, you could instead add this line to

/usr/ports/x11/xbindkeys_config/Makefile:

BUILD_DEPENDS=

xbindkeys:${PORTSDIR}/x11/xbindkeys

This will ask the xbindkeys_config build to install both ports.

Once your builds are complete, open an xterm and type:

% xbindkeys --defaults ~/.xbindkeysrc

% xbindkeys_config

The GUI in Figure 1-1 will appear.

Figure 1-1. The xbindkeys_config program

Creating a key binding is a simple matter of pressing the New button and typing a useful name into the Name: section. Then, press Get Key and a little window will appear. Press the desired key combination, and voilà, the correct mapping required by X will autofill for you. Associate your desired Action:, then press the Save & Apply & Exit button.

Any keyboard mappings you create using this utility will be saved to a file called ~/.xbindkeysrc.

• The xbindkeys web site (

http://hocwp.free.fr/xbindkeys/xbindkeys.html)

< Day Day Up >

Hack 5 Use the Mouse at a Terminal

Use your mouse to copy and paste at a terminal.

If you're used to a GUI environment, you might feel a bit out of your element while working at the terminal. Sure, you can learn to map hotkeys and to use navigational tricks, but darn it all, sometimes it's just nice to be able to copy and paste!

Don't fret; your mouse doesn't have to go to waste. In fact, depending upon how you have configured your system, the mouse daemon moused may already be enabled. The job of this daemon is to listen for mouse data in order to pass it to your console driver.

Of course, if you're using screen [Hack #12], you can also take advantage of its copy and paste mechanism.

1.6.1 If X Is Already Installed

If you installed and configured X when you installed your system, moused is most likely started for you when you boot up. You can check with this:

% grep moused /etc/rc.conf moused_port="/dev/psm0"

moused_type="auto"

moused_enable="YES"

Very good. moused needs to know three things:

•

• The mouse port (in this example, /dev/psm0, the PS/2 port)

•

• The type of protocol (in this example, auto)

•

• Whether to start at boot time

If you receive similar output, you're ready to copy and paste.

To copy text, simply select it by clicking the left mouse button and dragging. Then, place the mouse where you'd like to paste the text and click the middle button. That's it.

To select an entire word, double-click anywhere on that word. To select an entire line, triple-click anywhere on that line.

1.6.1.1 Configuring a two-button mouse

What if you don't have three mouse buttons? As the superuser, add the following line to /etc/rc.conf (assuming it's not already there):

moused_flags="-m 2=3"

This flag tells moused to treat the second, or right, mouse button as if it were the third, or middle, mouse button. Now you can use the right mouse button to paste your copied text.

To apply that change, restart moused:

# /etc/rc.d/moused restart Stopping moused.

Starting moused:.

Test your change by copying some text with the left mouse button and pasting with the right mouse button.

1.6.2 If X Is Not Installed

You can achieve the same results on a system without X installed.

You'll have to add the lines to /etc/rc.conf manually, though.

The example I've given you is for a PS/2 mouse. If you're using another type of mouse, read the "Configuring Mouse Daemon" section of man

Dans le document About the Author (Page 28-96)