Help, I've Fallen

Gary Kline and Dirk Myers

...A (( parenthetical)) forward by Gary Kline

Last month's was my first Q/A column--both questions and answers drawn from the -questions mailing list. I expanded most of the answers and presented them in brief cookbook style. Do

   % step-1 
   % step-2,
   ...
   % step-N

and the question is answered; problem solved.

Of the dozen or so responses in the following several days, while most were positive, there were many requests for more detail, more explaination.

Dirk Myers' mail pointed out specific suggestions that he thought would improve this column. Turned out that Dirk is a tech writer... and he has graciously volunteered his time and skills.

So this month, a new and improved column.

Q: Is there a way to remove that annoying ^M from a DOS text file under *BSD?

One way uses tr.

The tr command reads the infile, deletes all the ^M characters, (represented by the '\015' -- octal notation for the ASCII value of ^M) and writes the result to outfile. Next, the ``mv'' (move) command renames outfile to infile (and replaces infile as it does so).

You can find all the options for tr in its man page.

Another way to do this uses vi's global search/replace. This will also work fine, and may be more convenient if you have to edit the file for other reasons.

^V^M will look like just ^M when you type it in - the ^V escapes the ^M - and ^V means Ctrl-V and ^M means Ctrl-M.

Here, the g/^V^M/ tells vi to find every line containing a ^M, and the s///g finds whatever is between the the first two slashes and, each time it finds a match, substitutes the matched text with what is between the second set of slashes. We want to delete the ^M--not substitute it with anything--so the trailing slashes are empty. When there's no explicit expression to find, (that is, nothing between the first two slashes) vi assumes that you want it to find whatever you searched for last-- in this case, the ^M.

Q: How can I use my *BSD floppy drive to copy files to it (in this case, at work), and retrieve the files on my *BSD system at home. So far I've only seen examples that used floppies with a filesystem on them. Is there a simpler, more direct way?

You can treat the 'raw' floppy device as if it is a tape drive, and use typical UNIX tape tools to read/write, such as tar and cpio. (If, by some chance, you've got more than one floppy drive, you may need to change the '0' in the examples below to the device number of the floppy drive you're actually using.)

To copy the current directory onto a floppy to take home at night using tar:

(put the floppy in the drive, and cd to the directory where the files are; then )
% tar -cvf /dev/rfd0 .

To read it when you get home:

(put the floppy in the drive at home, cd to the directory where you want the files to be extracted. to extract the tarball use)
% tar -xvf /dev/rfd0

The flags -c and -x indicate create and extract mode, the v specifies verbose mode, and the f tells tar that the following argument is the file or device that tar acts upon. Here, it is the floppy device. In create mode, tar also needs to know what files or directories to create the archive from -- in this case, ``.'', the current directory.

With cpio:

(chdir to the directory where the files are)
% find -depth -print | cpio -oc > /dev/rfd0

To read a cpio archive from a tape drive (or any raw storage device, in this case a floppy drive):

% cpio -icd < /dev/rfd0

Since the cpio utility reads the list of files to archive from the standard input, the output of the find -depth -print is piped to cpio to tell it which files (in which directories, if any) to archive. The flags -i and -o indicate copy-in or extract mode and copy-out or create archive mode. The c tells cpio to use the old ASCII archive format, which is the most portable. And the d flag tells cpio to create directories where necessary. Since cpio writes to the standard output when archiving files, the > redirects the standard output to write directly to the floppy drive. When reading archives, the < reverses the process, telling cpio to take input directly from the floppy drive.

Q: What's the best way to get a listing of all the manual pages or a subset of them on *BSD?

Using the [t]csh:

% apropos *

will find them all. It will display the name and number of every man page and a brief summary.

% apropos 1

will show you all the man (1) pages;

% apropos N

will display the Nth man page group, and more if there is the number ``N'' in the description.

% apropos

is a good way to find utilities or programs for which there are man page entries. For example

% apropos uud

finds the uudeview utility whose name frequently escapes me.

uuencode(1), uudecode(1) - encode/decode a binary file
uudeview(1) - a powerful decoder for binary files

Q: Where is tset being called from when a person logs into a freebsd box? This is causing some real annoyances when I telnet from a xterm and after I login the tab stops are messed up on anything except a 80 column screen.

It's in .login. Or in .zlogin if you are using the zsh; or usually in your .profile otherwise.

  #csh .login file

  set noglob
  eval `tset -e^H -i^C -s -Q -m 'network:?xterm'`;
  unset noglob

  stty status '^T' crt -tostop
  

( etcetera ... )

Here the ``eval'' line is the critical line. eval causes the tset command to set erase to ^H, interrupt to ^C. The ``-s'' causes tset to print the sequence of shell commands that initialize your environment to stdout. ``-Q'' says to not display values for erase,, interrupt, and kill. The ``-m <mapping_string>'' specifies the mapping. Here the mapping is 'network:?xterm'.

Type man tset for many more options that will let you season your remote login sessions to taste.

Q: I've heard of using pkg_add over the net, somehow, but don't understand the exact details. Can you explain how this works?

If you'd rather not build a program from source and don't have the CD set, you can (as root) type:

(for FreeBSD)

# pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/packages-N.N.N/category/pkg

(for NetBSD)

# pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages-N.N.N/machine-architecture/category/pkg

and the package will be automatically be downloaded, uncompressed, unarchived, and installed.

As an explicit example,

# pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/packages-2.2.7/games/awele-1.0.tgz

Note that we are using the backslash for ``continuation'' demonstration purposes.

(for OpenBSD)

Not sure. There is a lot of information on compiling ports from source at openbsd.org. If someone from Openbsd will drop us a line, we'll publish the information next time.

To find out which programs are available, use your favorite browser to go to
http://www.freebsd.org/ports/ (FreeBSD)
http://www.netbsd.org/Documentation/netbsd/packages.html (NetBSD)
http://www.openbsd.org/ports.html (OpenBSD)
to find all of the categories; and within them the packages.

If you have any problems fetching a package, be sure you are typing the path correctly. This bit me (Gary Kline) more than once.

Your system will keep track of programs you've added using the pkg_add command, which can make maintaining your system easier. See man pkg_add, man pkg_info, and man pkg_delete for details.

Security Note: It's probably a good idea to install only those packages found on an official site. As with any software, it's possible for an unscrupulous person to have altered a package for their own ends. Sticking to official distribution sites is one of the better ways to protect yourself.

Q: I know that a certain file is on my system somewhere, but I'm not sure where. How can I find it?

There are (at least) two ways to do this.

The fastest way is to use locate. For example,

will show you a list of files named test.txt. The locate utility searches a database of file names to quickly find the file you're looking for. The only drawback to this is that if the file has been added (or moved) after the database has been updated (every Saturday in a default installation), locate won't find it, or will tell you the file is in the wrong place.

The thorough way to track down a file is to use a combination of find and grep.

% find / -print | grep test.txt

Here, the find command begins at the root directory, and produces a list of every filename on the system. That list is then piped to grep, which then prints out line that contains the phrase ``test.txt''. Looking for the file this way guarantees that you'll find it, but it takes a lot longer and consumes a relatively large amount of your system's resources. If you find yourself needing to use this method very much, you should consider rebuilding your locate database more often.

Q: Ok, how do I update the locate database every night rather than once a week?

In your favorite text editor, comment out this code from /etc/weekly by adding a ``#'' in front of each line:

        echo ""
        echo "Rebuilding locate database:"
        locdb=/var/db/locate.database
        touch ${locdb}; chown nobody ${locdb}; chmod 644 ${locdb}
        echo /usr/libexec/locate.updatedb | nice -5 su -m nobody 2>&1 |\
        fgrep -v 'Permission denied'
        chmod 444 ${locdb}

Add the same lines you just commented out into /etc/daily -- without the ``#'' symbols in front.

(The exact statements will vary a bit if you aren't using FreeBSD. Basically, just find the section that contains the line
echo "Rebuilding locate database:"
and comment out/move the entire section.)

<stddisclaimer.h>

Because the three *BSD may differ slightly, not all the examples shown here may work exactly as presented. The differences in shells is likely to be the largest factor here.

Yes, we have-no-OpenBSD

Gary Kline runs FreeBSD; Dirk Myers runs NetBSD on a 68k platform. If anyone running OpenBSD is interested in contributing to this column on a bi-monthly basis, please drop a line.

Tricks of the Trade

Since you are prob'ly your own system administrator, it makes sense to track any and all changes that you make to your system; including an explaination of your changes. I log every change to any system file with the date and my initials. Further, I make fairly detailed instructions of how to do a given task. Since there is a chance of hardware failure, it is a sound idea to keep a hard copy of both your notes and log.

About the authors

Gary Kline has been porting code since the late 1970's when he helped port several V6 utilities to V7 at Cal Berkeley. Recently he has taken on the internationalization of the *BSD utilities. When he isn't hacking code, he's hacking prose, or listening to jazz radio and drinking espresso.

Dirk Myers works at a company that designs and builds bar code scanners, usually in that order. Essentially a Mac user, he installed NetBSD/mac68k 1.2 on an old IIcx because it struck him as being a strange thing to do with a Mac. He now spends more time working on Un*x systems than he does MacOS systems, and shows no signs of returning to a Mac-only environment.

Gary Kline, kline@thought.org, and Dirk Myers, dirkm@buster.dhis.org