DæmonNews: News and views for the BSD community

December 2000 Get BSD New to BSD? Search BSD Submit News FAQ Contact Us Join Us
Search


Get BSD Stuff

Help, I've Fallen

by Gary Kline, David Leonard and Dirk Myers

And our World Renowned year-end presentation of the scads of topics that we Answerfolk have covered during the last year of the 20th Century, CE. [1]

And now, without further delay, here are some questions that we have found on the BSD mailing lists, have been asked in the cyber hallways, or which have been scribbled down on paper, wrapped around rocks, and hurled over the transom of the Answerguys' executive offices here in c-space [2].








Q1: How can I chage the glaring white bg of my xterm -- and maintain the darkblue that I like without constantly having to type in "$ xterm -bg ivory -fg darkblue -g 80x24" every time I want a new xterm?

A: One way to always have a darkblue on ivory xterm is to put the following two lines into your ~/.Xdefaults file:


/*
 * personal xterm entries
 */

XTerm*Background: ivory
XTerm*Foreground: darkblue


xrdb -merge ~/.Xdefaults

Here are the in-depth details:
When an X program starts up, it opens the file named by $XENVIRONMENT, (or $HOME/.Xdefaults-hostname by default). Then it loads the resources into the application (not into the server). [this from X(3) manpage] It also looks for application-defaults overridable by $XFILESEARCHPATH.

The 'standard' name for having server resources is ~/.Xresources, and indeed you put a "xrdb -load ~/.Xresources" into your ~/.xsession. ~/.Xdefaults is not meant to be loaded 'manually' like that..

Also worth checking out is XtResolvePathname(3) which describes the variable $XFILESEARCHPATH. You might notice that some programs, when installed, have two app-default files, one that ends in "-color" and one that doesn't. Their use is controlled by placing


	*customization: color

in the server resources. (.Xdefaults)

By default, XFILESEARCHPATH is taken as "%D" which expands to a complex default path. Part of the path might look like this


		/usr/X11R6/lib/X11/%l/%T/%N%C%S

For an xterm running with colour customisaion and in a japanese langaueg environment, the xterm program would load its app-defaults from

		/usr/X11R6/lib/X11/ja/app-defaults/XTerm-color

its instructive to list some of the environment vars together as used by X for resource configuration.

	XENVIRONMENT		- resources for a display
	XFILESEARCHPATH		- filename pattern for apps to find data files

If you'd like to have more flexibility, you can write a shell script--as simply or fancy as you like--and put in into a ~/bin directory. A script named, say, xmkterm might look like this:

#!/bin/sh

background=$1;
foreground=$1;
wXhsize=$3;

/usr/X11R6/bin/xterm -bg ${background} -fg ${foreground} -g ${wXhsize}


This would let you create any variety of xterms as needed with the command-line.


  $ xmkterm black green 132x55

Valid colour names can be found in /usr/X11R6/lib/X11/rgb.txt

Last, but not least, if your shell allows aliasing, you can define an alias that creates an xterm in your preferred style, and add the alias to the rc file the shell reads on startup. For example, if you use zsh, you could add the following line to your .zshrc:


alias newterm='xterm -bg ivory -fg darkblue -g 80x24 &'

Translated into csh-speak, that incantation is:


alias newterm 'xterm -bg ivory -fg darkblue -g 80x24 &'

Another way to do this is to use the -name argument to all X11 applications and have resource defaults control what goes on. This keeps everything in one place, so to speak.


	xterm -name XTerm-pine -e pine -i

This would load the normal 'XTerm' resources


 XTerm.utmpInhibit:              true
 XTerm.sameName:                 true
 XTerm.VT100.font:               fixed
 XTerm.VT100.scrollBar:          true

yet allow them to be overriden by specific 'XTerm-pine' resources


 XTerm-pine.VT100.scrollBar:     false
 XTerm-pine.VT100.geometry:      80x40
 XTerm-pine.zIconBeep:           0
 XTerm-pine.title:               pine
 XTerm-pine.iconName:            pine






Q2: I've got hundreds of files (scattered across several directories) named *.bak. Is there a SAFE way to remove only this files using some sort of script?

A: If you're sure you want to remove all .bak files without confirmation, use the -delete flag to find:


% find . -name "*.bak" -delete

There is no -delete in OpenBSD's find(1). The following works too.


	find . -name \*.bak | xargs rm -f

which is dangerous if files contain strange characters.. so the safer way is what you did below with -exec, or to use the -print0/-0 flags


	find . -name \*.bak -print0 | xargs -0 rm -f

This command deletes all the files which end with "*.bak" in the current directory, all the directories beneath the current directory, all the directories beneath those directory, and so on, as deep as the directories go (for most purposes, anyway).

Remember, though, that you won't get any kind of confirmation, so don't do this unless you're absolutely certain that this is what you want!

A safer way to do this (but more tedious if you're deleting a large number of files) is to use find's -exec flag to execute "rm -i" (remove, request confirmation) for each file found:


 % find . -name "*.bak" -exec rm -i {} ';'

When you use the -exec flag, the next several arguments are treated as a command. Empty curly-braces -- {} -- mark the spot where you'd like the filename to be filled in. You tell the find command that you've finished your -exec command by using a semicolon. (Since the shell will interpet a bare semicolon itself rather than giving the semicolon to the find command, we've enclosed the semicolon in quotes.)

A backslack will `escape' the colon as well, so that this works too:


 % find . -name "*.bak" -exec rm -i {} \;

Here is a way to remove ".bak" files in a single directory with a Bourne-style shell script:

#!/bin/sh

for f in $(find . -name "*.bak" -print)
do
     rm -i $f
done

This can also be done from the command line for /bin/sh, bash, zsh, ksh:


% for f in $(find . -name "*.bak" -print)
> do
> rm -i $f
> done

The man page on the find command is well worth reading. Find has several other options you can use to make sure that it locates the files you're looking for, and only the files you're looking for.

Here is a case where spending an hour or so plowing through the man pages plus experimenting with some of the shell scripts in /etc that use find will prove a sound investment.






Q3: What is meant by "passive ftp mode? // Help! i've got a direct link thru a site that just set up a firewall. how can i ftp thru this wall?

A: You need to use ftp in 'passive mode' where the remote site deals with the command-side of things rather than your end of the ftp connection. In "regular" mode, your computer makes a connection to the machine you're transferring files from, and the computer on the other side of the connection responds by opening a connection back to your machine. This won't work if your machine isn't directly reachable from the internet. In passive mode, both connections come from your computer. The server on the other end waits "passively" for your machine to connect.

Most applications that use FTP for file transfer check the environment variable FTP_PASSIVE_MODE to determine whether or not they should use passive mode connections. For csh, and csh-like shells:


% setenv FTP_PASSIVE_MODE YES

For bourne-like shells:


% export FTP_PASSIVE_MODE=YES

Will set this for the current session. To set this every time a shell is started, put the line into your shell's *.rc (initialization) file.

Under OpenBSD, passive mode is on by default. To turn off passive mode you set the environment variable $FTPMODE to 'active'.






Q4: How do I limit the size of my core files? ...

Set your core file size with the ulimit command (see 'help ulimit')


  % ulimit -c 20000

This sets the core file limit to 20000 blocks of 1024 bytes. For the limit to work, it must be set before you run the program. You can also set the limit in the .rc file for your shell, or systemwide in /etc/profile.

Note that the common trick under other operating systems to avoid core files by making a directory called 'core' will not work with most of the BSDs because core files are called 'core.progname'






Q5: How do I set up a mailbox that automatically forwards messages to the next person in a set of people? For example, I have an "admin" mailbox. I'd like the first message to go to Person A, the second message to go to Person B, and so on. Any ideas?

A: There are a couple of quick-n-dirty ways to get this working. If you're using procmail, all you need to do is set up rules to cover this case. For example, to alternate between two addresses, you can do something like:


:0
* ? perl -e ' '$a=qx/cat .counter/||0;$a++;system"echo $a > .counter";exit($a%2)
'
! persona@wherever.com

:0 E
! personb@wherever.com

You can also use chained .forward files in the admin account. A .forward file is often used to run a program every time mail is received (for example, procmail or vacation). Here, we're going to be a little bit sneaky and have the .forward file run a program that rewrites the .forward file. If this looks like a hack -- it is! Remember, up-front we said these were quick-and-dirty ways. If you have the admin in /home/admin, then the chained forwarding files


/home/admin/forwarda

and


/home/admin/forwardb

will do the job.


forwarda:

persona@wherever.com
"|cp forwardb .forward"


forwardb:

personb@wherever.com
"|cp forwarda .forward"

The problem with round robin mail distribution is that you need to keep state. If you can assume that emails will arrive at random intervals, you could set up aliases to admin0, admin1, and admin2 in your sendmail.cf file.

In sendmail.cf, change the definition of ForwardPath to start with /etc/mail/forward.$u
O ForwardPath=/etc/mail/forward.$u:$z/.forward.$w:$z/.forward
and create the file /etc/mail/forward.admin to contain


  	"|sh -c '/usr/sbin/sendmail -t admin.$(expr $(date +%s) % 3)'"
  

This last suggestion is untested, and will tend to balance the messages over time, but won't guarantee a strict round-robin. If any sendmail wizards out there in web-land send along corrections, we will certainly pass them along.

Footnotes to the December column

[1] If 2000 is part of the 21st Century, the 20th will be the only century with 99 years.
[2]. What? no transom where you live? Wow... .







Following are the questions and our answers for the 2000 calender year.







About the Authors

Gary Kline has been porting code since the late 1970's. When he isn't hacking code, he's hacking prose or quasi-poetry, or listening to jazz radio and slurping down espresso.

For four years he has been writing the software equivalent of a mind-machine, dubbed Muuz, and has already released some alpha code for FreeBSD. Check the FreeBSD ports tree if you are interested.

http://muuz.deadbbs.com will have the documentation and source under CVS.

[home| mail]

David Leonard is a PhD student in the Department of Computer Science and Electrical Engineering at the University of Queensland, Brisbane, Australia.

His area of research is QoS-adaptive component software architectures, and in his spare time is a developer for the OpenBSD project. That said, David enjoys living the quiet life with his wife, Kylie and cat, Mu. He especially enjoys frequenting Moreton Bay's many fabulous places to eat. Mmmmm!

[home| mail]

Dirk Myers makes Unix systems do things which are useful for document control.

[mail]




Author maintains all copyrights on this article.
Images and layout Copyright © 1998-2004 Dæmon News. All Rights Reserved.