There are always certain things a person needs to customize and configure to get a program working just right. On this page I'll offer some of my customizations. I've found these work just fine on the Debian releases Slink through Sarge, a.k.a. Debian 2.1.x through the current Testing. More than likely, these tips will work with other distributions using the same packages.
On Debian invoking the startx script begins the process to starting the X server. startx performs a few file checks and then by default runs the /etc/X11/xinit/xinitrc script which in turn runs the /etc/X11/Xsession script which then starts the X server and the window manager listed in /etc/X11/window-managers. (Whew! Of course the actual process is more involved, but I'm leading up to something here...)
If you examine /etc/X11/Xsession closely, you will find that it checks for the existence of ~/.xsession (~ refers to your home directory, e.g. /home/joe) and will invoke the commands in that file instead of itself. This means that if you create ~/.xsession it must at least have the exec command to start your favorite window manager. As an example here is my ~/.xsession:
#!/bin/sh # ~/.xsession created on 17 Dec 1999 # Merge in local App Defaults from specific directory where they can be # kept in separate files for each application. Names are case sensitive # and must match the resource name. export XAPPLRESDIR=$HOME/.app-defaults # Start some nice programs. Each command must be started as a background # process with "&" or the script will stop and not reach the window # manager if [ -x /usr/X11R6/bin/xscreensaver ]; then xscreensaver & fi if [ -x /usr/bin/X11/xv ]; then xv -quit -rmode 5 ~/Pix/10074812a.jpg & fi # Get the window manager started. Must be started with "exec" so X # server will shut down when it is exited. exec icewm
For the most part things should be self-explanatory except perhaps what I am doing with the $XAPPLRESDIR environment variable. By setting this variable to a directory I can store Xresources settings in individual files for each application without having to wade through a large ~/.Xresources file (for example, if I want to customize the Netscape resources file, it is approximately 500k!). Be aware case is critical when naming the resources files. The xprop command is helpful in determining the application name. Just run xprop in an xterm window and then move your mouse pointer over the window in question and click the left (first) button. You should be greeted with a number of lines of output and the specific line you will look for is:
WM_CLASS(STRING) = "xterm", "XTerm"
My experience has shown that the second name string is the one to use when naming an Xresources file.
Somewhere in the transition to XFree 4.0.x the default app-defaults file for XTerm was trimmed considerably. Most notable is that colored console apps suddenly had a washed-out blue and a few other colors incorrect. Also, by default, the Home and End keys on a US PC keyboard are not handled properly.
Copy and paste the following text into your favorite editor and save it as XTerm in your app-defaults directory (see the above section).
! /etc/X11/Xresources/xterm ! Uncomment the following lines to make xterm appear much like a virtual ! console, so that ANSI colors will make more sense. XTerm*background: black XTerm*foreground: white XTerm*scrollBar: False XTerm*saveLines: 100 XTerm*cursorColor: green1 ! Make the backspace key generate ^? instead of ^H, per Debian keyboard policy. ! Make the delete key generate ^[[3~ instead of ^?, per Debian keyboard policy. ! Make the home and end keys appear to always be in keypad-application mode. ! Include override for BackSpace because older xterms do not understand the ! backarrowKey resource. *VT100.Translations: #override ~Meta <Key>BackSpace: string("\177")\n\ <Key>Delete: string("\033[3~")\n\ <Key>Home: string("\033OH")\n\ <Key>End: string("\033OF") ! Enable Colour by default. *VT100*colorMode: on *VT100*boldColors: on *VT100*dynamicColors: on ! Uncomment this use color for underline attribute !*VT100*colorULMode: on !*VT100*underLine: off ! Uncomment this to use color for the bold attribute !*VT100*colorBDMode: on ! Uncomment this to use the bold/underline colors in preference to other colors !*VT100*colorAttrMode: on *VT100*color0: black *VT100*color1: red3 *VT100*color2: green3 *VT100*color3: yellow3 *VT100*color4: blue3 *VT100*color5: magenta3 *VT100*color6: cyan3 *VT100*color7: gray90 *VT100*color8: gray30 *VT100*color9: red *VT100*color10: green *VT100*color11: yellow *VT100*color12: blue *VT100*color13: magenta *VT100*color14: cyan *VT100*color15: white *VT100*colorUL: yellow *VT100*colorBD: white !This can be useful if you have an IntelliMouse. It maps the button !events generated by the wheel *VT100*translations: #override \ !Ctrl <Btn4Down>: scroll-back(1,halfpage) \n\ !Lock Ctrl <Btn4Down>: scroll-back(1,halfpage) \n\ !Lock @Num_Lock Ctrl <Btn4Down>: scroll-back(1,halfpage) \n\ ! @Num_Lock Ctrl <Btn4Down>: scroll-back(1,halfpage) \n\ <Btn4Down>: scroll-back(5,line) \n\ !Ctrl <Btn5Down>: scroll-forw(1,halfpage) \n\ !Lock Ctrl <Btn5Down>: scroll-forw(1,halfpage) \n\ !Lock @Num_Lock Ctrl <Btn5Down>: scroll-forw(1,halfpage) \n\ ! @Num_Lock Ctrl <Btn5Down>: scroll-forw(1,halfpage) \n\ <Btn5Down>: scroll-forw(5,line)
In the top section of this file my favorite default colors are set so I don't have to specify them on the command line if I want to use XTerm in a menu item in IceWM. The second section forces the corrent Home and End key behavior for a US PC keyboard. The third section sets the colors back to the old defaults (matches what you get on the Linux console and RXVT). Finally, the last section appears to add some functionality for wheel mice. I've found mine to work fine.
Like most everything else, this isn't too hard provided you get the right information!
XFree treats the wheel as two extra buttons on the mouse, in my case as buttons 4 and 5. My particular wheel mouse is a PS/2 MS clone with two buttons on either side of the wheel. The wheel acts as the third button so 3-button emulation isn't required.
Here is the relevant portion of my /etc/X11/XF86Config-4 file:
# ********************************************************************** # Core Pointer's InputDevice section # ********************************************************************** Section "InputDevice" # Identifier and driver Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/mouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection
Once you've experienced using a wheel mouse, you'll wonder how you got along without it. Plain mice are so boring and cumbersome. However, if you use a lot of LessTif (Motif) apps, you'll probably find the wheel non-functional. Just about every other widget set supports it. Reading Slashdot with the wheel is the only way to go!
The GNU version of ls included with Debian 2.1 has the capability of displaying its output (the contents of a directory) in color. By default this capability is disabled and seemed a bit tricky for me to get working how I thought it should.
I found the following code in the .bashrc file in root's home directory:
# You may uncomment the following lines if you want `ls' to be colorized: # export LS_OPTIONS='--color=auto' eval `dircolors` alias ls='ls $LS_OPTIONS' alias ll='ls $LS_OPTIONS -l' alias l='ls $LS_OPTIONS -lA'
As it is, it works perfectly for root along with the following alias in root's .profile:
alias ls='ls -F --color'
However, I copied these files to ~/.bashrc and ~/.bash_profile (as ~/.profile didn't seem to work) expecting things to work. Well, they didn't. As a result I tinkered with things until I wound up with the following code in ~/.bashrc:
# You may uncomment the following lines if you want `ls' to be colorized: export LS_OPTIONS='-F --color' eval `dircolors -b ~/.colordb` alias ls='ls $LS_OPTIONS'
And in ~/.bash_profile I included the same code as well:
# You may uncomment the following lines if you want `ls' to be colorized: export LS_OPTIONS='-F --color' eval `dircolors -b ~/.colordb` alias ls='ls $LS_OPTIONS'
The reason for including the code in both is that ~/.bashrc is read by a non login shell (an xterm invoked without the "-ls" switch) and ~/.bash_profile is read by a login shell (the one a getty starts when you log in and an xterm started with the "-ls" switch. See Where to configure Bash for more information). This way both types of shells allow a colorized ls output.
The colors that dircolors will give ls to use for each file type is configurable by telling it to look at the specified file rather than its internal database. I simply used the following command to generate a file I could use to customize it:
dircolors -p > .colordb
To get a list of switches use the --help command line option which generally works with all GNU utilities.
Now, I had a file I could load in the eval line above with my favorite color scheme which is included here as colordb.txt. If you compare it to the standard output of dircolors -p you'll noticed I added several file types so that certain types like documents (.pdf, .ps, .html, etc) all show as the same color. As near as I can tell I get my desired ls output in any shell whether it is the console or an xterm.
The following assumes just enough networking has been configured to allow ppp connection to an ISP. Any other network configuration will surely complicate matters...
When I installed Debian, Exim was listed as a Mail Transfer Agent, MTA, capable of easier configuration then Sendmail and better suited for a dial-up machine. Unfortunately, I don't think too many people are using it as I didn't find a HOWTO that provided a quick start. So I used Netscape mail until I received this email on the Debian Laptop mailing list. Using it as a guide, I wound up configuring Exim using eximconfig as root as follows:
Step 1. 2 - Internet site using smarthost Step 2. localhost - "visible" name Step 3. none - other names Step 4. none - relayed domains Step 5. none - relayed networks Step 6. n - use RBL Step 6a. isp.mail.host - smarthost to handle outgoing mail Step 7. my_user - name to send root and postmaster mail to Step 8. n - create new /etc/alias file Step 9. y/n - confirm answers Note! Step 6a appeared when doing a new install but wasn't present when running eximconfig a second time on the laptop.
Now /etc/exim.conf is created but needs a little more help. fire up your favorite editor as root and uncomment the following lines at the end of exim.conf:
###################################################################### # REWRITE CONFIGURATION # ###################################################################### # There are no rewriting specifications in this default configuration file. # This is an example of a useful rewriting rule---it looks up the real # address of all local users in a file *@localhost ${lookup{$1}lsearch{/etc/email-addresses}\ {$value}fail} bcfrF
Next create /etc/email-addresses and add a line like the following (substituting your names as appropriate):
george gburns@gracie.allen.edu
Hopefully, if you send an email to your login name it will be delivered in your /var/spool/mail/user_name mailbox. Next connect to your ISP and try sending a message to yourself. If you have fetchmail configured (quite easy) you should be able to run fetchmail -a -k which will retrieve all your mail from your ISP and not delete it (in case something isn't set just right). Now you should see your test message in your mailbox and then you can use fetchmail to retrieve your mail from now on and use your favorite mailer. A couple good sources of help are the Mail-HOWTO and the Mail-User-HOWTO for getting your local mail working. If you need a source for mail administration, then check out Mail-Administrator-HOWTO.
I would like to thank Drew Parsons for posting the message that put me on the right track with Exim.
Update: Recently I started playing with Ethereal to learn more about what was going on with my network connections. To my surprise I learned that some process was querying my ISP's DNS for an address of the local hostname!
After checking over all of my resolver files, it became obvious that Exim
was the culprit. A bit of searching through the
Debian Bug Tracking System led me
to bug 188447
which suggested the following patch to eximconfig
:
--- /usr/sbin/eximconfig Tue Mar 5 00:05:40 2002 +++ eximconfig Thu Apr 10 13:52:14 2003 @@ -172,7 +172,7 @@ # Message on other systems "============================================================================== What is the `visible' mail name of your system? This will appear on -From: lines of outgoing messages.", +From: lines of outgoing messages and as the SMTP server's name:", 'visiblename', $syshostname, # Check against regexp @@ -501,13 +501,27 @@ # MAIN CONFIGURATION SETTINGS # ###################################################################### +# This specifies the name of the current host. This is used in the HELO +# command for outgoing SMTP messages, and as the default for +# `qualify_domain'. If it is not set, Exim calls `uname()' to find it. +# If this fails, Exim panics and dies. If the name returned by `uname()' +# contains only one component, Exim passes it to `gethostbyname()' in +# order to obtain the fully qualified version. +# +# In other words: If you don't set this, exim is likely to ask DNS to +# find out its own hostname, even if only called as `exim -bp', or +# `exim -q', on an empty queue. On a dialup system, asking DNS may well +# bring up your internet connection - essentially for nothing. + +primary_hostname = $visiblename + # Specify the domain you want to be added to all unqualified addresses # here. Unqualified addresses are accepted only from local callers by # default. See the receiver_unqualified_{hosts,nets} options if you want # to permit unqualified addresses from remote sources. If this option is # not set, the primary_hostname value is used for qualification. -qualify_domain = $visiblename +# qualify_domain = # If you want unqualified recipient addresses to be qualified with a different # domain to unqualified sender addresses, specify the recipient domain here.
I simply added the primary_hostname =
option and gave it the
value in $HOSTNAME
and commented out the
qualify_domain =
option in /etc/exim/exim.conf
.
I'm happy to say that the unnecessary DNS lookups have ceased.
The default configuration for Mutt is for it to assume your login name as your mail name at your local machine plus domain. Well, this is fine and dandy on a standard network, but doesn't work well at all when your login name differs from the user name on your ISP. To work around this tell Mutt to set your From: and Reply-to: headers in your ~/.mutt/muttrc file as follows:
my_hdr From: Nate Bargmann <n0nb@networksplus.net> my_hdr Reply-to: Nate Bargmann <n0nb@networksplus.net>
This forces Mutt to show your real ISP email address. So far I've had no problems with this simple fix.
Depending on how Bash was started, it will either be started as a login shell or a non-login shell. While there are technical differences I won't jump into here, Bash does use two separate files for its runtime configuration. Deciding which to use is the topic of this section.
Called as a login shell when you login to your Linux system or when XTerm is started with the -ls switch, Bash will read the contents of ~/.bash_profile and configure itself accordingly. If Bash is started as a non-login shell, then ~/.bashrc is read for its configuration. However, the two files will be nearly redundant if you want non-login shells to act and look in much the same way as login shells.
One simple fix is to place the following three lines into ~/.bash_profile:
if [ -f ~/.bashrc ]; then source ~/.bashrc fi
Then keep the common configuration in ~/.bashrc and any stuff for login shells in ~/.bash_profile.
One of the more annoying things I noticed was encountering strange symbols in the headers and text of email messages particularly if the author was from outside the U.S.A. A discussion thread on the Debian-User mailing list revealed the answer.
With the introduction of glibc 2.0, the C library has supported Locales which is a way of writing programs so that text in the program can be translated to many languages and the proper language selected by each user through an environment variable. By default the variable is set in ~/.bashrc as:
export LANG=C
Well, this is a default that selects a character set common to the U.S.A. and English text. However, this setting appears to disable the Locale function and the result is often strange characters on your screen. For example, German folk often have the umlaut (ä) in their name and this will appear as some weird character such as an upside down question mark.
The solution involves changing the environment variable to:
export LANG=en_US
Note! Of course you should match your own locale if you are not in the United States.
Log out and log back in and then take a look at those emails. Remarkable improvement, eh? I also noticed quite an improvement when using Netscape and Mozilla.
Original content Copyright © 1997-2024 Nate Bargmann NØNB n0nb@n0nb.us
any other content copyright by respective author(s).
This page last modified February 10, 2005 |