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.

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:

To copy text, simply select it by clicking the left mouse button and drag
ging. 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.

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:.

{mospagebreak title=Hack 6: Get Your Daily Dose of Trivia}

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

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 moused
. It gives explicit details on figuring out what type of mouse you have and what type of protocol it understands. It even includes a section on configuring a laptop system for multiple mice: one for when on the road and one for when the laptop is attached to the docking station.

For example, if you’re using a USB mouse, the only difference is that the port is
/dev/usm0
instead of
/dev/psm0
.

A serial mouse physically plugged into
COM1
would be
/dev/cuaa0
. You may have to experiment with the type, as
auto
doesn’t work with all serial mice. Again, the manpage is your best reference.

See Also

man moused

Documentation on enabling mouse support in NetBSD athttp://www.netbsd.org/Documentation/ wscons/

Documentation on enabling mouse support in OpenBSD at http://www.openbsd.org/faq/faq7.html)

Brighten your day with some terminal eye candy.

As the saying goes, all work and no play makes Jack a dull boy. But what’s a poor Jack or Jill to do if your days include spending inordinate amounts of time in front of a computer screen? Well, you could head over to http://www.thinkgeek.net/ to stock up on cube goodies and caffeine. Or, you could take advantage of some of the entertainments built into your operating system.

A Fortune a Day

Let’s start by configuring some terminal eye candy. Does your system quote you a cheery, witty, or downright strange bit of wisdom every time you log into your terminal? If so, you’re receiving a fortune:

If you’re not receiving a fortune, as the superuser type
/stand/sysinstall
. Choose
Configure
, then
Distributions
, and select
games
with your spacebar. Press Tab to select
OK
, then exit out of
sysinstall
when it is finished.

Then, look for the line that runs /usr/games/fortune in your ~/.cshrc file:

% grep fortune ~/.cshrc /usr/games/fortune

If for some reason it isn’t there, add it:

% echo ‘/usr/games/fortune’ >> ~/.cshrc

Don’t forget to use both greater-than signs; you don’t want to erase the contents of your .cshrc file! To test your change, use the source shell command, which re-executes the contents of the file. This can come in handy if you’ve updated an alias and want to take advantage of it immediately:

% source ~/.cshrc Indifference will be the downfall of mankind, but who cares?

If you’d also like to receive a fortune when you log out of your terminal, add this line to the end of your .logout file. If you don’t have one, and there isn’t one by default, you can create it and add this line in one step:

% echo ‘/usr/games/fortune’ > ~/.logout

Note that this time I used only one greater-than sign, as I was creating the file from scratch. If the file already exists, use two greater-than signs to append your new line to the end of the existing file.

Believe it or not,
fortune
comes with switches, some of which are more amusing than others. I’ll leave it to you to peruse
man fortune
.

Pursuing Trivia

I’m a trivia buff, so I love using the
calendar
command. Contrary to logic, typing
calendar
won’t show me this month’s calendar (that’s the job of
cal
). However, I will get an instant dose of trivia, related to the current date:

Cool. I had forgotten it was the anniversary of the Hoosac tunnel, an event that put my hometown on the map.

It’s an easy matter to automate the output provided by
calendar
. If you want to see your trivia when you log in or log out, simply add a line to your .cshrc or .logout file. Because the line you add is really just a path to the program, use the output of the
which
command to add that line for you:

% echo `which calendar` >> .cshrc

Again, don’t forget to append with >>, or have noclobber set in your .cshrc file [Hack #2].

Sundry Amusements

Of course, there are several other date and time related mini-hacks at your disposal. Here are two you might enjoy.

The current time.
Ever wonder what time it is while you’re working on the terminal? Sure, you could use
date
, but the output is so small and boring. Try this the next time you want to know what time it is:

% grdc

Whoa, you can see that one from across the room. That’s not a bad idea if you want to send your cubicle buddy a hint.

I’ve been known to add /usr/games/grdc to my ~/.logout. When I log out, my terminal displays the time until I press Ctrl-c and log in again. That’s sort of a built-in password protected screen saver for the terminal.

The phase of the moon.
Have you ever read
man pom
? It has one of the more useful descriptions I’ve seen:

The pom utility displays the current phase of the moon. Useful for selecting software completion target dates and predicting managerial behavior.

Sounds like Dilbert had a hand in that one. If I add the line /usr/games/pom to my ~/.cshrc, I’ll learn a bit about astronomy when I log in:

Gee, that reminds me of my old DOS days when I discovered ansi.sys. Yes, your terminal is capable of color and you’re looking at your possible color schemes! (It likely looks much more exciting on your terminal, since it’s not in color in this book.)

If you see some colors that appeal to you, add them to your terminal. For example, this command will set the foreground color to yellow and the background color as blue:

% vidcontrol yellow blue

Note that you can use only colors 1 through 7 as background colors; you’ll receive a syntax error if you try to use colors 8–15 in your background. Try out the various combinations until you find one that appeals to your sense of taste. You can even add a border if you like:

% vidcontrol -b red

These settings affect only your own terminal. If you want, add the desired vidcontrol lines to your ~/.cshrc file so your settings are available when you log into your terminal.

If you have problems finding your cursor, try:

% vidcontrol -c blink

or:

% vidcontrol -c destructive

Changing the cursor affects all virtual terminals on the system. If other users complain about your improvement, this will bring things back to normal:

% vidcontrol -c normal

See Also

man fortune

man calendar

man vidcontrol

The games packages, in NetBSD and OpenBSD

{mospagebreak title=Hack 7: Lock the Screen}

Secure your unattended terminal from prying eyes.

If you work in a networked environment, the importance of locking your screen before leaving your workstation has probably been stressed to you. After all, your brilliant password becomes moot if anyone can walk up to your logged in station and start poking about the contents of your home directory.

If you use a GUI on your workstation, your Window Manager probably includes a locking feature. However, if you use a terminal, you may not be aware of the mechanisms available for locking your terminal.

As an administrator, you may want to automate these mechanisms as part of your security policy. Fortunately, FreeBSD’s screen locking mechanism is customizable.

Using lock

FreeBSD comes with
lock
(and it’s available for NetBSD and OpenBSD). Its default invocation is simple:

Without any switches,
lock
will request that the user input a key which will be used to unlock the terminal. This is a good thing, as it gives the user an opportunity to use something other than her login password. If the user tries to be smart and presses Enter (for an empty password), the
lock
program will abort.

Once a key is set, it is required to unlock the screen. If a user instead types Ctrl-c, she won’t terminate the program. Instead, she’ll receive this message:

Key: lock: type in the unlock key. timeout in 10:59 minutes

Did you notice that timeout value of 15 minutes? At that time, the screen will unlock itself, which sorta diminishes the usefulness of locking your screen. After all, if you run into your boss in the hall, your 5-minute coffee break might turn into a 25-minute impromptu brainstorming session.

To lock the terminal forever, or at least until someone types the correct key, use the
-n
switch. If the system is a personal workstation,
-v
is also handy; this locks all of the virtual terminals on the system, meaning a passerby can’t use Alt-Fn to switch to another terminal.

As an administrator, you can assist users in using the desired switches by adding an alias to /usr/share/skel/dot.cshrc [Hack #9]. This alias removes the timeout and locks all terminals:

alias lock /usr/bin/lock -nv

Using autologout

If you use the
tcsh
shell, you also have the ability either to lock your session or to be logged out of your session automatically after a set period of inactiv
ity. As an administrator, you can set your policy by adding a line to /usr/ share/skel/dot.cshrc.

Do be aware, though, that a user can edit her own ~/.cshrc file, which will negate your customized setting.

The
autologout
variable can accept two numbers. The first number represents the number of minutes of inactivity before logging out the user. The second number represents the number of minutes of inactivity before locking the user’s screen. Once the screen is locked, the user must input the password to unlock it. If the screen is not unlocked in time, the user will be logged out once the shell has been idle for the logout period of minutes.

The manpage is pretty vague on how to set those two numbers. For example, if you try:

set autologout = 30 15

users will receive this error message when they try to log in:

set: Variable name must begin with a letter.

That’s a deceptive error message, as this variable does accept numerals. The correct invocation is to enclose the two numbers between parentheses:

set autologout = (30 15)

This particular setting will log out a user after 15 minutes of inactivity. The user will know this happened as the terminal will resemble:

%
Password:

After 30 minutes of inactivity (or 15 minutes after the screen was locked), the user will be logged out and see this:

%
Password:auto-logout

Consider whether or not your users tend to run background jobs before globally implementing autologout. Also see "Use an Interactive Shell” [Hack #11], which allows users to reattach to their terminals.

Enforcing Logout

What if you do want to enforce a logout policy that users can’t change in their shell configuration files? Consider using
idled
, which can be installed from /usr/ports/sysutils/idled or built from source. This utility was designed to log out users either after a configured period of inactivity or after they’ve been logged in for a certain amount of time.

Once you’ve installed
idled
, copy the template configuration file:

# cd /usr/local/etc/ # cp idled.cf.template idled.cf

Open /usr/local/etc/idled.cf using your favorite editor. You’ll find this file to be well commented and quite straightforward. You’ll be able to configure the time before logout as well as when the user will receive a warning message. In addition, you can refuse logins, set session timeouts, and provide for exemptions.

See Also

man lock

man tcsh man idled

man idled.cf

The
idled
web site (http://www.darkwing.com/idled/)

{mospagebreak title=Hack 8: Create a Trash Directory}

Save “deleted” files until you’re really ready to send them to the bit bucket.

One of the first things Unix users learn is that deleted files are really, really gone. This is especially true at the command line where there isn’t any Windows-style recycling bin to rummage through should you have a change of heart regarding the fate of a removed file. It’s off to the backups! (You do have backups, don’t you?)

Fortunately, it is very simple to hack a small script that will send removed files to a custom trash directory. If you’ve never written a script before, this is an excellent exercise in how easy and useful scripting can be.

Shell Scripting for the Impatient

Since a script is an executable file, you should place your scripts in a directory that is in your path. Remember, your path is just a list of directories where the shell will look for commands if you don’t give them full path-names. To see your path:

In this output, the shell will look for executables in the bin subdirectory of
dru
’s home directory. However, it won’t look for executables placed directly in my home directory, or /home/dru. Since bin isn’t created by default, I should do that first:

% cd
% mkdir bin

As I create scripts, I’ll store them in /home/dru/bin, since I don’t have permission to store them anywhere else. Fortunately, no one else has permission to store them in my bin directory, so it’s a good match.

The scripts themselves contain at least three lines:

#!/bin/s
h
# a comment explaining what the script does
the command to be executed

The first line indicates the type of script by specifying the program to use to execute the script. I’ve chosen to use a Bourne script because that shell is available on all Unix systems.

Your script should also have comments, which start with the
#
character. It’s surprising how forgetful you can be six months down the road, especially if you create a lot of scripts. For this reason, you should also give the script a name that reminds you of what it does.

The third and subsequent lines contain the meat of the script: the actual command(s) to execute. This can range from a simple one-liner to a more complex set of commands, variables, and conditions. Fortunately, we can make a trash script in a simple one-liner.

The Code

Let’s start with this variant, which I found as the result of a Google search:

You should recognize the path to the Bourne shell, the comment, and the
mv
command. Let’s take a look at that
$1
. This is known as a positional parameter and specifically refers to the first parameter of the
trash
command. Since the
mv
commands takes filenames as parameters, the command:

mv $1 ~/.trash/

is really saying,
mv
the first filename, whatever it happens to be, to a directory called .trash in the user’s home directory (represented by the shell shortcut of
~
). This move operation is our custom “recycle.”

Before this script can do anything, it must be set as executable:

% chmod +x ~/bin/trash

And I must create that trash directory for it to use:

% mkdir ~/.trash

Note that I’ve chosen to create a hidden trash directory; any file or directory that begins with the . character is hidden from normal listings. This really only reduces clutter, though, as you can see these files by passing the -a switch to ls . If you also include the
F
switch, directory names will end with a /:

% ls -aF ~ .cshrc .history .trash/
bin/ images/ myfile

Replacing rm with ~/bin/trash

Now comes the neat part of the hack. I want this script to kick in every time I use
rm
. Since it is the shell that executes commands, I simply need to make my shell use the
trash
command instead. I do that by adding this line to ~/.cshrc:

alias rm trash

That line basically says: when I type
rm
, execute
trash
instead. It doesn’t matter which directory I am in. As long as I stay in my shell, it will
mv
any files I try to
rm
to my hidden trash directory.

Running the Code Safely

Whenever you create a script, always test it first. I’ll start by telling my shell to reread its configuration file:

What happened here? I passed the shell more than one parameter. The a* was expanded to a, aa
,
aaa
, and
aaaa
beforetrash
could execute. Those four parameters were then passed on to the
mv
command in my script. However,
trash
passes only the first parameter to the
mv
command, ignoring the remaining parameters. Fortunately, they weren’t removed, but the script still didn’t achieve what I wanted.

You can actually have up to nine parameters, named
$1
to
$9
. However, our goal is to catch all parameters, regardless of the amount. To do that, we use
$@
:

mv $@ ~/.trash/

Make that change to your script, then test it by removing multiple files. You should now have a script that works every time.

Taking Out the Trash

You should occasionally go through your trash directory and really remove the files you no longer want. If you’re really on your toes you may be think
ing, “But how do I empty the trash directory?” If you do this:

% rm ~/.trash/*

your trash directory won’t lose any files! This time you really do want to use rm, not trash. To tell your shell to use the real rm command, simply put a
in front of it like so:

% rm /trash/*

Voila, empty recycling bin.

Hacking the Hack

One obvious extension is to keep versioned backups. Use the
date
command to find the time of deletion and append that to the name of the file in the
trash
command. You could get infinitely more complicated by storing a limited number of versions or deleting all versions older than a week or a month. Of course, you could also keep your important files under version control and leave the complexity to someone else!