Teaching OSS to Share

Say you're doing some programming, or trying out an older audio program, and you get some form of the following cryptic error:

unable to open `/dev/dsp', Device or resource busy

What does it mean and what can you do about it?

As to what it means - basically, an application somewhere isn't being very nice and sharing, like we have all be taught to do. Or it wants to hog the sound device all to itself and another app won't let it go. /dev/dsp is the device pointer for the default "dsp" or digital sound processor and, as audio remains a bit of an Achilles heel for Linux, there can be problems in the sandbox.

So what you need to do is to figure out which app currently has locked, so maybe you can quit that application to allow our other one to access it. You might think of using lsof or fuser to figure it out. So you check:

$ lsof /dev/dsp
$ fuser /dev/dsp

But unfortunately, it won't show you anything. I think this is because /dev/dsp is just an affectation, which allows Linux to point wherever it really wants to.

In this case, it is the /dev/snd/* files. It is here you want to see who is grabbing things:

$ ls /dev/snd
controlC0  hwC0D2    pcmC0D0p  pcmC0D1p  pcmC1D0c  seq
controlC1  pcmC0D0c  pcmC0D1c  pcmC0D2c  pcmC1D0p  timer
$ lsof /dev/snd/*
COMMAND    PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
VirtualBo 4083 jdarnold  mem    CHR 116,10          4395 /dev/snd/pcmC0D0c
VirtualBo 4083 jdarnold  mem    CHR  116,9          4390 /dev/snd/pcmC0D0p
VirtualBo 4083 jdarnold   40r   CHR  116,2      0t0 4102 /dev/snd/timer
VirtualBo 4083 jdarnold   42u   CHR 116,10      0t0 4395 /dev/snd/pcmC0D0c
VirtualBo 4083 jdarnold   43u   CHR 116,12      0t0 4411 /dev/snd/controlC0
VirtualBo 4083 jdarnold   44r   CHR  116,2      0t0 4102 /dev/snd/timer
VirtualBo 4083 jdarnold   45u   CHR  116,9      0t0 4390 /dev/snd/pcmC0D0p
VirtualBo 4083 jdarnold   46u   CHR 116,12      0t0 4411 /dev/snd/controlC0
kmix      4155 jdarnold   12u   CHR 116,12      0t0 4411 /dev/snd/controlC0
kmix      4155 jdarnold   13u   CHR  116,5      0t0 4560 /dev/snd/controlC1
$ fuser /dev/snd/*
/dev/snd/controlC0:   4155  4800
/dev/snd/controlC1:   4155
/dev/snd/pcmC0D0c:    4800m
/dev/snd/pcmC0D0p:    4800m
/dev/snd/timer:       4800
$ ps -c 4800
PID CLS PRI TTY      STAT   TIME COMMAND
4800 TS   19 ?        SLl    0:12 /usr/lib/virtualbox/VirtualBox -comment Debia

Pretty conclusive proof that it is VirtualBox using the device. So let's see what it looks like after I quit out of VirtualBox:

$ lsof /dev/snd/*
COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kmix    4155 jdarnold   12u   CHR 116,12      0t0 4411 /dev/snd/controlC0
kmix    4155 jdarnold   13u   CHR  116,5      0t0 4560 /dev/snd/controlC1
$ fuser /dev/snd/*
/dev/snd/controlC0:   4155
/dev/snd/controlC1:   4155
$ ps -c 4155
PID CLS PRI TTY      STAT   TIME COMMAND
4155 TS   19 ?        S      0:00 kmix [kdeinit] -autostart

kmix, the KDE sound mixer program, is pretty good about things, and thus we no longer have a conflict:

$ ./dspinfo
Information on /dev/dsp:

Defaults:
sampling rate: 8000 Hz
channels: 1
sample size: 8 bits
block size: 1023 bytes

Supported Formats:
mu-law
unsigned 8-bit (default)
signed 16-bit little-endian
signed 16-bit big-endian
signed 8-bit
unsigned 16-bit little-endian
unsigned 16-bit big-endian

Capabilities:
revision: 1
full duplex: yes
real-time: yes
batch: no
coprocessor: no
trigger: yes
mmap: yes

Modes and Limits:
Device    Sample    Minimum   Maximum
Channels  Size      Rate      Rate
--------  --------  --------  --------
1         8      1000    100000
1        16      1000    100000
2         8      1000    100000
2        16      1000    100000

dspinfo is a small program I adapted from the exerpt for the old O'Reilly book Linux Multimedia Guide, which is Chapter 14. Programming Sound Devices. As I said, OSS (Open Sound System) is an old Linux standard, pretty much passed by in these days of 2.6 kernels.

Symbolic Help

Today's obscure Unix command is namei, or the ol' "follow a pathname until a terminal point is found" command. You pass it a pathname and it will print out each "piece" of that path name, tell you what it is, and move down. This is particularly handy for figuring out what, if any, parts of a path are some kind of symbolic link. For instance, I have a partition mounted on /data, where I've created a folder for my user to use:

$ ls -l /data
total 20K
drwxr-xr-x 8 jdarnold users 4.0K Jun 21 14:58 jdarnold
drwx------ 2 root     root   16K May  4 15:54 lost+found
$ ls -ld data
lrwxrwxrwx 1 jdarnold users 14 May  7 10:21 data -> /data/jdarnold
$ namei /home/jdarnold/data/message.backup
f: /home/jdarnold/data/message.backup
d /
d home
d jdarnold
l data -> /data/jdarnold
d /
d data
d jdarnold
- message.backup

Not the most critical tool in your belt, but it still might come in handy, especially, as the man page says, in those times of "too many levels of symbolic links" errors.

Does anyone really know what time it is?

There was an interesting discussion on the opensuse mailing list about finding out which command is going to get used when you type something in. The Original Poster (OP) couldn't figure out why some options found in the time man page weren't working:

$ time -o ls
bash: -o: command not found

real    0m0.008s
user    0m0.000s
sys     0m0.000s
$ time --help
bash: --help: command not found

real    0m0.003s
user    0m0.000s
sys     0m0.008s
$

Of course, any veteran of the commandline could tell you it is not executing the time command as documented in the man page, but some other time command, in this case bash's builtin time command, which doesn't have the -o or the --help options. So you have to tell the shell exactly which command you are looking to execute, or use bash's man page or help command to get info on its version:

$ /usr/bin/time -o t.out ls
$ /usr/bin/time --help
Usage: /usr/bin/time [-apvV] [-f format] [-o file] [--append] [--verbose]
[--portability] [--format=format] [--output=file] [--version]
[--help] command [arg...]
$ help time
time: time [-p] PIPELINE
Execute PIPELINE and print a summary of the real time, user CPU time,
and system CPU time spent executing PIPELINE when it terminates.
The return status is the return status of PIPELINE.  The `-p' option
prints the timing summary in a slightly different format.  This uses
the value of the TIMEFORMAT variable as the output format.
times: times
Print the accumulated user and system times for processes run from
the shell.

So the discussion evolved into answering the important question - "How can you tell which command is actually getting executed when you don't type in the full path?" One hint is in the question - use the which command:

$ which time
/usr/bin/time
$ which -a time
/usr/bin/time
$

Hmm, now that doesn't work! That's what I had always used, especially the -a flag, which should show all versions of the command, rather than just the first one. It turns out a better option is bash's builtin type command, which does know about aliases and builtins:

$ type time
time is a shell keyword
$ type -a time
time is a shell keyword
time is /usr/bin/time
$

Okay, that's much better, although the suggestion to use the -p option just makes it revert back to the mysteriously incomplete which output:

$ type -ap time
/usr/bin/time
$ help type
type: type [-afptP] name [name ...]
For each NAME, indicate how it would be interpreted if used as a
command name.

If the -t option is used, `type' outputs a single word which is one of
`alias', `keyword', `function', `builtin', `file' or `', if NAME is an
alias, shell reserved word, shell function, shell builtin, disk file,
or unfound, respectively.

If the -p flag is used, `type' either returns the name of the disk
file that would be executed, or nothing if `type -t NAME' would not
return `file'.

If the -a flag is used, `type' displays all of the places that contain
an executable named `file'.  This includes aliases, builtins, and
functions, if and only if the -p flag is not also used.

The -f flag suppresses shell function lookup.

The -P flag forces a PATH search for each NAME, even if it is an alias,
builtin, or function, and returns the name of the disk file that would
be executed.
typeset: typeset [-afFirtx] [-p] name[=value] ...
Obsolete.  See `declare'.

So I learned about the type command, which is really what you want to use. But then I started investigating the which command, which led to a surprise:

$ type -a which
which is aliased to `_which'
which is /usr/bin/which
$ type -a _which
_which is a function
_which ()
{
local file=$(type -p ${1+"$@"} 2>/dev/null);
if test -n "$file" -a -x "$file"; then
echo "$file";
return 0;
fi;
hash -r;
type -P ${1+"$@"}
}

Whoa, where did that come from? A quick perusal of the bash man page tells me bash, on start up:

       When  bash  is  invoked  as an interactive login shell, or as a non-interactive shell
with the --login option, it first reads and executes commands from the file /etc/pro-
file,  if  that  file exists.  After reading that file, it looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that order, and reads and  executes  commands  from
the  first  one that exists and is readable.  The --noprofile option may be used when
the shell is started to inhibit this behavior.

So I checked out /etc/profile, which is a very long shell script doing all kinds of interesting things, worth a post all in its own. But one of the last things it does is to execute /etc/bash.bashrc, which again is a fascinating script setting a whole bunch of mostly bash-specific things, again worth a look at in itself. In there, a whole bunch of aliases get set up and there is this section:

if test "$is" = "bash" ; then
#
# Other shells use the which command in path (e.g. ash) or
# their own builtin for the which command (e.g. ksh and zsh).
#
_which () {
local file=$(type -p ${1+"$@"} 2>/dev/null)
if test -n "$file" -a -x "$file"; then
echo "$file"
return 0
fi
hash -r
type -P ${1+"$@"}
}
alias which=_which
fi

Interesting. I wonder why they do this instead of using the /usr/bin/which command in the path? It doesn't seem to improve anything over the system which command except add an unnecessary layer of obfuscation.

But I will look over my .bashrc file, which, much like my .emacs file, has accompanied me for many years, to see what I should remove as redundant, as the openSUSE standard one does a lot of it already. I wonder how standard it is on other Linux distros? Looks like I'll have to check the MACHTYPE environment variable for the Linux type:

jdarnold@opensuse $ echo $MACHTYPE
i686-suse-linux
$ 

jarnold@redhat $ echo $MACHTYPE
i386-redhat-linux-gnu
$

Keeping the Agent Around

I answered an interesting question on the Suse Forums today, and I thought I would log my answer here too. Teresa wanted to know how to have ssh-agent remember her passkey across multiple shell logins and the like. I answered the question here for how to do it when you are using X, but she was doing everything from the console and so didn't have the luxury of an overarching environment.

When you run 'ssh-agent', it starts up a process that listens on a local socket, and prints out some info you can use to set environment variables with, which then tell other programs where to ask it for info:

$ ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-CzngL4914/agent.4914; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4915; export SSH_AGENT_PID;
echo Agent pid 4915;

So normally you "eval" the results of this to actually create the environment variables, so you put something like this in your .bashrc:

eval `ssh-agent -s`

But if instead you dump that to a file, you can now use this in any other virtual terminal, say, or another screen session, rather than killing the old one, starting up a new ssh-agent, and adding the key again.

$ ssh-agent -s > sshx
$ cat sshx
SSH_AUTH_SOCK=/tmp/ssh-CzngL4914/agent.4914; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4915; export SSH_AGENT_PID;
echo Agent pid 4915;
$ eval `cat sshx`
Agent pid 4915
$ printenv |grep SSH_
SSH_AUTH_SOCK=/tmp/ssh-CzngL4914/agent.4914
SSH_AGENT_PID=4915

Now any keys you ssh-add to this ssh-agent will be effective in any other shell. It doesn't look like you need to use the nohup command with ssh-agent, as it automagically works as a daemon already, so as long as you use the correct environment variables, you should be communicated with that one no matter what.

Being GRUBby only once

The 'grubonce' command is a pretty little script if you are playing with various kernels. Basically, it lets you pick a GRUB menu boot option that it will boot from once and then go back to booting the old default. This is handy if you want to test out a new kernel and you want a safe way to check it out. This way, if the boot fails, your reboot will be back into the 'good' option. It is an undocumented perl script found in /usr/sbin, and looks like it implements this algorithm for you:

Booting once-only - GNU GRUB Manual 0.97

$ su -
Password: my root password
# grubonce
0: OpenSUSE 10.2 - Kernel-2.6.18.8-0.1-default
1: linux (/dev/hdb6)
2: Windows
3: Floppy
4: Kernel-2.6.18.8-0.1-xen
# grubonce 4
Using entry #4: Kernel-2.6.18.8-0.1-xen
# ^d
$

Pretty slick if you ask me!

Swap Market

How to find out if you are using swap? These days, you should have plenty of memory, even with the piggish apps we all use. So you might want to find out how often you are using the swap space, to see if it is time to splurge on a RAM. Well, it is vmstat to the rescue:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
1  2    204   4340  29984 140436    0    0   281   122  238  773 25  6 62  7
1  2    204   5636  26188 139620    0    0  1612  3793 1111 1953  5  5  1 89
0  2    204   8032  25420 133464    0    0  1516    30 1115 2342  6  6  0 87
1  1    204   7020  26068 130084    0    0  1444    89 1042 2289 10  7  0 83
0  1    204  13604  21472 129780    0    0  2158    65  937 1911 22 21  0 56
1  2    204   5884  22888 127960    0    0  1640     2 1180 2495  8  7  2 83

The main column you want to look at is the swap 'so' column. This tells you the amount of memory 'swapped out'. In my case, it is zero, so we're looking good, although I only have 1gb of RAM. I still think I'll grab another gigabyte. The '5' means to update the status every 5 seconds. And the first line shows the average of all the numbers since the machine was last rebooted, which is cool. As I've taken to shutting down all my machines every night, it isn't as interesting as it would have been a month ago, when the machine would run for weeks at a time.

Locate This!

I can never remember how to update my locate database. locate is a very useful little command, which searches your hard drive for any file or path name that contains the letters you ask for. It works much faster than doing find because it builds a database of filenames and searches that rather than actually running around the disk hierarchy.

But it requires that the database be kept up to date. This is one case where the Linux world has it all over the FreeBSD world. The GNU locate updates itself just by passing it the '-u' flag. But the FreeBSD locate doesn't do this. Rather it has a couple of mysterious command files that are carefully hidden away in the bowels of FreeBSD. The main file, as documented in the man page, is /etc/periodic/weekly/310.locate. This is one of the periodic commands that is run, but it, for some reason, is only run weekly, which doesn't seem to me to be often enough. I've moved it to be /etc/periodic/daily/305.locate, to get it to run every night. Not sure if that's a good idea, but I like my /var/db/locate.database to be more up to date! Oh, and I had to edit the /etc/periodic.conf file to move it up to a daily ritual. This file overides the /etc/defaults/periodic.conf file, so it now includes:

# Make the update locate db script run nightly

# 305.locate
daily_locate_enable="YES"		# Update locate *daily*!

The other option is the script /usr/libexec/locate.updatedb. If you run this as root, it complains that it would expose every file on the computer and you probably don't want to do that. The 310.locate script runs it as "nobody", which only picks up files and directories that are world readable, which is less of a security threat. And you can't run it unless you are root anyway, because root can't update the database. So it is easier to just run the periodic script if you need to update it on the fly. But if I run this every night, that should be enough.

Out Damn Spot!

An interesting, yet common, question came up on the FreeBSD questions mailing list - "How do I delete a file that has a leading dash?" For instance, say you have a file called "-testing". Here's what happens if you try to delete it normally:

$ rm -testing

rm: illegal option -- t

usage: rm [-f | -i] [-dIPRrvW] file ...

unlink file



That's because the rm command thinks the '-t' is supposed to be an option (like the -f to force or the -r for recursive), and it doesn't recognize that option. Your first try might be to quote the file name:

$ rm "-testing"

$ rm \-testing


But that doesn't help, as it isn't the shell that's complaining but rather the rm command, which still sees the "-t" and doesn't understand it.

But as the rm man page reminds you, there are several easy ways around this problem. All of the following will work:

$ rm -- -testing

$ rm /home/usr/-testing

$ rm ./-testing



Because now the '-' isn't the first character. The '--' is a general way of telling pretty much any command that all options have ended and the rest of the command line should be processed as arguments to the command (often filenames). But the most obscure way of doing this had to be the answer using the find command to delete it by its inode number:

$ ls -i

 9232923 -testing

$ find . -inum 9232923 -exec rm {} \;



Isn't Unix wonderful? I was looking forward to seeing the answers to this question, and the thread didn't disappoint. There are so many ways of using the tools to solve problems. The find method would work for other, tough characters too.

Time in a bottle

Following up on a post yesterday, I think I have my PC-BSD machine set up for NTP. I followed some advice from the Handbook (of course), as well as some from a thread on the FreeBSD Questions mailing list. I wanted it to be an NTP server for my internal network, and to sync the date periodically from the 'net. It runs 24/7, so I can't depend on a reboot to set the time. So here's what I did.

First I added the following to my /etc/rc.conf:

ntpd_enable="YES"

This sets it up so that the script at /etc/rc.d/ntpd gets run at boot up, and the ntpd daemon is allowed to run. But now we have to create a config file for it, at a bare minimum. My /etc/ntp.conf file looks like:

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server pool.ntp.org
driftfile /var/db/ntp.drift
restrict 192.168.204.100 mask 255.255.255.0 nomodify notrap
restrict localhost

As I'm located in North America, I'm using the pool servers from there, as mentioned here. I don't think I need to specify the driftfile, as it is the same as the default. And combining Matthew Seaman's post with the handbook page, I came up with the restrict lines to allow my internal network to up date from my server. The 'restrict localhost' line actually allows all access to the localhost. Makes sense, eh? Be sure to not make the same mistake the poster in the mailing list made, and just add a 'restrict default ignore' line to the rc.conf file, like the handbook suggests. This means that the NTP daemon can't do anything, even on the local host, which isn't all that useful now is it?

Now I can run the command with the -q flag (which mimics what the older 'ntpdate' command used to do). This just runs the ntpd daemon, does its thing, and exits. This is what it looks like:

$ ntpd -q

[... long pause while it does its dance ...]

ntpd: time set +39.114227s



And now my time is spot on, at least according to Time & Date.com. So now I fire up the daemon and we should be all set:

$ /etc/rc.d/ntpd start

Starting ntpd.



You can use the ntpq command to ask about it. Here we'll ask about the list of peers it is using:

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

 static-141-156- .GPS.            1 u    1   64    1   49.416   -0.157   0.001

 tire.patch.com  63.192.96.3      3 u    -   64    1  118.075   -3.792   0.001

 gandalf.llorien .INIT.          16 u    -   64    0    0.000    0.000 4000.00

 elrond.llorien. .INIT.          16 u    -   64    0    0.000    0.000 4000.00



There are a bazillion commands for ntpq, which I'm sure at least one person out there cares about, but for us mere mortals, we've pretty much exhausted the subject!

Mangled up in blue

Just found out about a cool little GNU utility that takes a "mangled" C++ subroutine name and de-mangles it to show you its declaration. Kind of a specialized thing, but sometimes when you are debugging code and you see what the C++ compiler does to your function names, you are concerned. It's good to see there is some rhyme and reason to it.


$ c++filt _ZN8DiscTypeC1ENS_4TypeE

DiscType::DiscType(DiscType::Type)



GNU Binary Utilities: c++filt

Where oh Where has my little command gone?

While perusing some port stuff, as I try to figure out which port utility to use, I came across this little command - whereis. Now, I've actually used it before, when I couldn't find the md5 command (I didn't have /sbin in my PATH as a user). But I didn't realize it also searches the port tree for programs, which is pretty cool! For instance:


$ whereis firefox

firefox: /usr/X11R6/bin/firefox /usr/ports/www/firefox

$ whereis lsof

lsof: /usr/ports/sysutils/lsof


whereis(1)

Much nicer than some of the other ways I've used to search the ports, and more inclusive, as it even tells me if I've already had it installed. My normal method for searching ports is via the Freebsd.org web page for ports. I have a Firefox quicksearch set up, so I can pop into Firefox's address bar and type 'ports lsof' and immediately do the search. It is very simple to set this up.

• Go to the Freebsd.org ports page here


• Right click on the "Search ports for: " text entry box


• Select the "Add Keyword for Search" menu item


• Give it a name (say "FreeBSD port search") and a keyword (I use 'ports' - this is what you'll type in the address bar). Select a folder to store this "bookmark". The "Quick Searches" one is a good place:-) Then click Add.
• 
  

Now you can click in the address bar and type 'ports lsof' and it will immediately do the search. This is very nice and can be done with any search-type text box. See this posting on Lifehacker.com for a good starter kit for quicksearchs:

Fifteen Firefox Quick Searches

What is all this stuff?

Cool little tip I found while reading the fourth edtion of The Complete FreeBSD. Change directory into /bin and get a one line description of what all that stuff is:


$ cd /bin

$ man -f * |grep " - "



You can also use 'whatis' instead of 'man -f'. The grep gets rid of all the lines where there is "nothing appropriate" in the man files.

loader.conf

The loader.conf file is used to specify lots of load time options, used by loader(8). The most obvious use for it is to disable (or enable) the splash screen display. Some of the FreeBSD "distros" like PC-BSD use a splash screen by default, but if you are like me, you're going to want to watch FreeBSD while it goes to work. You can edit either /boot/loader.conf or, if you have a shared /boot/loader.conf, you can instead put local configuration stuff in /boot/loader.conf.local.  So to turn of the splash screen shown by PC-BSD, you add or change the line:

splash_bmp_load="NO"

while "bitmap_name" is the name of the splash screen to load.

You can see helpful examples of loader.conf stuff in /usr/share/examples/bootforth/.

loader.conf

man release

Cool man page that talks about how the official FreeBSD release is actually built. All kinds of crazy info that almost no one would ever be interested in. But it is great to see it documented, although I wonder about how up to date it is, as one of its examples shows how FreeBSD 4.9 was made!

man release

Debugging PCI hardware

I'm having a problem on my system, in that it doesn't seem to be able to find my SoundBlaster AWE-32 (oh yeah, cutting edge stuff:-) sound card. I just ran into this command:

$ pciconf -lv

This lists all the PCI devices that FreeBSD knows about. Unfortunately, it doesn't seem to notice my card at all. I'll have to follow the current freebsd.questions thread, where someone else has a similiar problem.

pciconf

portsnap - a better cvsup

There's a new cat in the forest when it comes to keeping your /usr/ports tree updated - portsnap. It does it a little better than trust old cvsup.

Good discussion about it here on the PC-BSD forums:

portsnap instead of cvsup

A short discussion about portsnap and why it is better than cvsup:

FreeBSD Portsnap

And, of course, the FreeBSD.org doc page about it:

Using Portsnap

pgrep and pkill

New as of 5.3 are the commands pgrep and pkill. They are related to ps and killall respectively, in that they show process status and can kill a running app, only they allow a more flexible manner of specifiying which process(es) you are interested in.

pgrep / pkill

Directory tree

Here's a cool find command line that will print out a reasonably nice looking directory tree:

$ find ./ -type d -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'

And the output looks like:

|____
|____.bashprompt
|    |____bashthemes
|    |____functions
|____.ddd
|    |____sessions
|    |____themes
|____.dia
|    |____objects

Don't ask me what it does or how it does it! It was posted by Warren B. on the questions list. It uses the find out put of directories via sed, which does the formatting.

nohup

I was reading the FreeBSD Questions mailing list (an always fascinating source of information), when I came across this response by David G. to someone who was having a problem with their KDE taskbar and desktop disappearing:

if you can get a command line up, can you do "nohup kicker &"?


(I have to restart kicker every month or two)

I found it interesting because I had never heard of either nohup or kicker! So, being the curious sort, I decided to look into both.

nohup

First up was this nohup command. First stop is, of course, the man page for nohup. But it is its usual terse self, telling me something about "at this time sets the signal SIGHUP to be ignored.". Well, I'm a programmer, and I'm still not sure what this means! A little more Googling leads me to this definition:

nohup : Runs a command that keeps running after you log out

Ah, now I get it. Normally, when you run a program in the background (by appending the & to the command), it automagically stops running when you completely logout. This isn't always true, as a program can disconnect completely from your session and continue running (this is what a daemon does). But if you have a program that isn't normally a daemon, or something you want to leave running after you've logged out (say, if you log in as root to get a server to run), you can use the nohup command. So David is saying that he is re-running this kicker command as a daemon process, and using nohup means it will stay running after he logs out.

kicker

A quick search on the KDE home page lead me to this page: The Kicker Handbook. It is headlined with this grammatically challenged note:

Kicker is the KDE application starter panel and is also capable of some useful applets and extensions. It usually resides on the bottom of the desktop.

Ah, so it is the task bar that runs along to bottom of the monitor. So the nohup kicker & command restarts the kicker process for others to use. See, you just never know when there is an interesting comment on the FreeBSD Questions mailing list!

fortune and fame

The fortune command spills out a small witticism or other interesting quote. I've talked about it before here, where I pointed out there was a FreeBSD tips fortune file.

Well, it's pretty easy to add your own quote file, but I can never remember how to do it, so I'm documenting it here.

fortune generally reads its data files from /usr/share/games/fortune - all the files that have a '-o' appended are "offensive" ones. You can pass a quote file (soon I'll tell you how to make one) on its command line and it will use that one. The special file name "all" will use all the ones in the "standard" places. Other useful options are -a, to include "offensive" quotes, -e, to consider them all to have equal sizes (otherwise it chooses which file based upon the size of the file), and the -l/-s flags to show only long or short ones.

To build your own fortune file, create a simple text file that has no extension and is a list of strings, separated by a line that has just a '%' on it. It would look something like this:

It's amazing how many people in this world are born at third base,
and think they've hit a triple.
Albert L. Lilly III
%
Eagles may soar, but weasels don't get sucked into jet engines.
Todd C. Somers
%
There is no psychiatrist in the world like a puppy licking your face.
Ben Williams
%

Then run the strfile command on it, which generates a .dat file with indices into this quote file for fortune to use:

$ strfile quotes

So now you can run fortune on this file:

$ fortune quotes

The easiest way to integrate this into the normal fortune lookup is to put it into the /usr/share/fortune directory, but that isn't usually writable by normal folks. This means you need to create an alias to do it:

$ alias fortune="fortune -ae all ~/quotes"

The -a says to include the "offensive" ones, the -e says to chose equally among the files, the 'all' says to include all the standard ones and then I add my own file at the end.

Again, don't forget about the freebsd-tips fortune file:

$ \fortune freebsd-tips

gives you a fortune from the tip file. I used the backslash to avoid the fortune command getting replaced by my alias (all of this discussion assumes you are using bash for a shell). To see if it is working correctly add in the -f flag, which displays the files it will use:

$ \fortune -fae all ~/quotes

___% /usr/share/games/fortune
___% fortunes
___% fortunes2
___% freebsd-tips
___% murphy
___% startrek
___% zippy
___% fortunes2-o
___% limerick
___% murphy-o
___% fortunes-o

Again, note the backslash to "quote" the f, so that alias expansion doesn't happen. It's a nice little shortcut if you think an alias is getting in the way.

For some reason, the FreeBSD.org man pages on the web, found at FreeBSD Hypertext Man Pages don't have the 'fortune' - probably a bug.

strfile