Devin Reade

GNO Consortium | Home | GNO/ME

Public Projects | System Administration | General Computing | Parallel Computing | Compilers | Linux Links

Cryptography and Security | Physics Resources | Humour

Other Pages of Interest


Expunging RedHat / Fedora / CentOS Annoyances

This page is a collection of information regarding getting rid of what I consider to be annoyances in the standard RedHat and derivitive (such as CentOS and Fedora) distributions. If you happen to like the specified "features" as RedHat ships them, then more power to you. However don't bother to drop me mail saying, "That isn't an annoyance; it's a great feature!"; such mail will be ignored.

Submissions for additions and corrections to this page are welcome; see the address at the bottom of this page. If I happen to agree with you (this list was created mainly for my benefit and that of a few friends), I'll include it.

How To Control Your Environment

This page refers to shell rc files. These are configuration files for your shell. A few come into play. For tcsh and csh, they may include:

For bash and sh they may include: Comments made about shell rc files may refer to one or more of the above files, or files that are sourced from the above files. For an explanation of the roles these files play, see your shell man page.


Default Locale

"Locales" affect the way a computer displays its data. It is a customization that permits an internationalization of the system by affecting character sets, what words a program displays, and other things.

The traditional locale (the one used before the concept of locales was introduced into computing) is known as the "C" locale, since it has its origins in the C programming language.

Red Hat is good for its support of locales. It has selected en_US as its default locale which, while being self-centered, can be excused. After all, if someone prefers a different locale they can always select it during the installation process or change it later.

My complaint with Red Hat in this matter is that there is no way to select the C locale during the installation process; it is just not an option. (I would also contend that the C locale should be the "default" default locale ...)

How to fix it:

  1. In the file /etc/sysconfig/i18n, add "C" (without the quotes) to the value of the SUPPORTED variable, if that variable exists. (The SUPPORTED variable existed on earlier RedHat distributions, but was removed for modern distributions.) Note that the value of the SUPPORTED variable is a colon-delimited list.
  2. Change the LANG variable to read:
    	LANG="C"
    
    You may want to keep a copy of the old LANG line, commented out by preceeding it with a # character, so that you can at some point in the future determine what locale was used during installation. (This can be useful in certain pathological cases.)
The change will be effective for all new logins. If your users want to use a different locale, let them set it in their own environments.


Getting Rid of Colourized Listings

Edit the two files /etc/DIR_COLORS and /etc/DIR_COLORS.xterm and change the lines

        COLOR tty
to
        COLOR none
This won't effect any existing shell sessions, but you should see the difference in any new ones.


Getting Rid of Colourized Source (emacs)

In your $HOME/.emacs file, you probably have something like the following:

        ; Turn on font-lock mode for Emacs
        (cond ((not running-xemacs)
               (global-font-lock-mode t)
        ))

Comment it out using semicolons.


Getting Rid of Colourized Source (vi)

This is actually caused by the files /etc/profile.d/vim.* setting an alias for the command vi to point at vim. Just comment the alias lines in those files.

Commenting them out is better than deleting the files because the next time you do an update, you should wind up with either an .rpmnew or .rpmsave file. If you're smart, you've got a cron job looking for the existence of such files, and thus will be notified when the upgrade decides to reenable your vim aliases.

(Rant: If people want to run vim, let them run vim, but don't foist it on the rest of us.)


Getting Rid of the Bell

For tcsh and csh, this is controlled by the shell rc files. In a suitable spot, add in the line

        set nobeep

For bash, this is controlled by the readline routines, and therefore by the files /etc/inputrc (globally) and $HOME/.inputrc (on a user-by-user basis). You want to add the following line:

        set bell-style none

If you're running Konsole in KDE, go into "Settings" --> "Bell" and set it to "None". You will probably want to save your settings for other Konsole instances via "Save as Default". Note that this only affects the current and new Konsole instances; ones that are already running will not be affected.

Note that this doesn't necessarily get rid of the bell in all circumstances, but it's a start (especially with the Konsole change, above). For example, vim will sometimes beep at you, overriding (or ignoring) your default settings. In such cases, you should consult the documentation for the problematic application.


Allowing CTRL-D to Exit the Shell

This (I believe) is primarily a csh/tcsh problem. In the shell rc files, look for a line of the form:

        set ignoreeof
change this to the following, adding it if necessary:
        unset ignoreeof

Killing Klipper

Klipper is that annoying clipboard tool that, ever time you click on a URL, will bring up a dialog asking which asks you what browser you want to run it in. Which means that you cannot cut and paste URLs. (Or if you can, it is certainly nonintuitive.)

Another web page on the Internet mentioned that you can turn this off globally by renaming the autostart klipper.desktop file (found, on RH systems, in /usr/share/autostart). However, when I did this I found that something in KDE would lock up the machine when KDE first starts up. This is definitely rude behavior, and not something that a non-privaleged user should be able to do (*grumble*). This was true even if the klipper.desktop file was moved to another directory. (Afterthought: Was this because I had klipper-related config files left over in my $HOME/.kde directory hierarchy? I don't know.)

Therefore, the mechanism that I used to disable this mis-feature was to edit $HOME/.kde/share/config/klipperrc and set the following line thus:

    URLGrabberEnabled=false
Note that this is effective only for the current user.

You can also disable it globally by setting the same value in the /usr/share/config/klipperrc file. Note, though, that this won't affect users who already have an overriding value in their personal klipperrc file.


Dumping the Graphical Splash Screen

That's the graphical screen that comes up on the initial boot. I find it annoying (obviously :) and worse, it is a problem if you've got a serial console.

Grub

If the file /etc/grub.conf or /boot/grub/grub.conf exists, you're probably using the grub boot loader. In this case, edit the respective grub.conf file and:

  1. Comment out the line containing the word "splashimage".
  2. On recent distributions, you'll see the word "hiddenmenu". Comment out that line, too.
  3. Also on recent distributions, you will see the word "quiet" in the list of kernel arguments. Remove that word.
You also need to modify the /etc/sysconfig/init file and change
    GRAPHICAL=yes
to
    GRAPHICAL=no

Note that at least with older versions (circa RH8, if I remember correctly) it was sometimes necessary to redo this procedure after performing a major system upgrade; Red Hat seemed to like to add this "feature" back in. I wouldn't be surprised if this is still the case.

(Thanks to Magnus Naeslund for providing part of this information, back before I started using grub.)

LILO

If you use the LILO boot loader, you can disable it by editing the file /etc/lilo.conf and commenting out the line:

	message=/boot/message
After you edit that file, you must run the command lilo for it to take effect.


Disabling the CD Autorun Mechanism

By default (after about RH8 or so) autorun(1) is active on the system. It causes the autorun file on data CDs to be executed automatically upon load, and permits kscd to immediately run audio CDs.

This autorun mechanism can be disabled (in KDE) by deleting the file $HOME/.kde/Autostart/Autorun.desktop. If you wish to later reenable this feature, you can copy the Autorun.desktop file from the /etc/skel hierarchy.

I don't know if this problem exists under GNOME nor, if it does, how to fix it.


Meta/Alt Key Shortcuts No Longer Work

I first noticed this problem with FC3. It also exists in FC4, FC6, (and probably FC5), CentOS 5.0, CentOS 5.1, CentOS 5.2, and probably all newer distributions.

If your applications' alt or meta key shortcuts no longer work, it's probably the case that the key mappings are wrong.

  1. Solution 1 (recommended): Create the file $HOME/.Xmodmap containing the following:

        keysym Alt_L = Meta_L Alt_L
    
    Mode 644 is sufficient. You need to log out and log back in again for this to take effect. You do not need to reboot.

  2. Solution 2: Create the file $HOME/.xmodmaprc with the same line in it as shown above. Then create the file $HOME/.xinput.d/default (which may also be mode 644) and in that default file add the following line:

        xmodmap $HOME/.xmodmaprc
    

The above works for KDE. I make no gaurantees for GNOME, but it's probably fine there, too.

You might want to also check out http://cweiske.de/howto/xmodmap/allinone.html


Changing the Default Window Manager

First off, if you've used switchdesk or a similar mechanism to explicitly set the desktop for a particular user, the following procedure has no effect.

However, if you would like the default desktop for new users to be something other than the usual Gnome, then you need to edit (or create) the file /etc/sysconfig/desktop and (assuming you want the default to be KDE), ensure that it has the following line:

    DESKTOP="KDE"

Contact Me

Last Updated: 19 Dec 2008

[Image: Apple II viewable page]