"Linux Gazette...making Linux just a little more fun! "

After typing the same command or editing the same rc-file for the dozenth time the idea of a short executable shell-script will gradually rise to the surface of my mind. As an example, last year after much trial-and error I figured out how to start my S3 X-server in 16-bit mode. This was great, but I found that there were a few programs which preferred to be run in 8-bit mode. Typing startx -- -bpp 16 and startx -- -bpp 8 began to become tiresome; then it dawned on me that I could write a shell script for each color-depth which would do the typing for me. One of them looks like this:

        #!/bin/sh
        # x16: starts x in 16-bit mode
        startx -- -bpp 16

Just a simple little script (made executable with chmod +x x16) but so handy!

Encouraged by this, it occurred to me that changing window-managers could be done in a similar way. I normally use fvwm2, but lately I've been fooling around with one of fvwm's hacked offspring, the Afterstep window-manager. Since I didn't have Afterstep's configuration quite as usefully customised as my mainstay fvwm2's, I didn't want to use it the majority of the time. Rather than editing ~/.xinitrc each time I wanted to switch to Afterstep, then again to switch back, I copied ~/.xinitrc twice. The first copy is .xinitrc-f and it's just my normal copy. The second, .xinitrc-a starts Afterstep instead. The scripts which control this are as follows:

        #!/bin/sh
        # xa: starts x with afterstep
        cp ~/.xinitrc-a ~/.xinitrc ; startx 

and

        #!/bin/sh
        # xf: starts x with fvwm2
        cp ~/.xinitrc-f ~/.xinitrc ; startx

Of course, while in an X-session another window-manager can be easily started from a menu. I spend a fair amount of time working in a console session without X running, in which case the above scripts are useful.

It just occurred to me as I write this that these tasks could be as easily done using aliases or functions in ~/.bashrc. The only difference I suppose would be that shell-functions are memory-resident whereas the scripts aren't.

These examples may seem self-evident or trivial to the unix-gurus out there, but they were part of the learning process for me. Perhaps this piece will encourage the beginners out there to try some similar scripting.

Here's a discovery I made recently concerning rxvt, the memory-saving alternative to xterm. I received an email message recently in response to my article last month concerning S-lang applications, in which I opinionated about rxvt vs. xterm. The poster of the message wondered whether there is any way to use shift-page-up and shift-page-down to scroll the rxvt window, similar to the way console screens (and xterms) scroll. I had tried to get this to work without success, and some usenet messages had led me to believe that without patching the source rxvt just wouldn't scroll from the keyboard.

Recently I installed the S.u.S.E. distribution, but didn't install the supplied rxvt package. I recompiled rxvt version 2.19 in this new environment, and to my surprise the above-mentioned scrolling keys worked! This piqued my curiosity, so I began prowling through the directory hierarchy searching for the difference in config files which made this behaviour possible. I came up with two differences: first, there was a new entry in the ~/.Xmodmap file. The lines

 

           keycode 64 = Meta_L
           keycode 0x6D = Multi_key

had been added to the "keycode 22 = BackSpace" line which I had in my previous installation. Second, the /etc/termcap file was different than the ones I'd seen before; a new rxvt stanza had been included which looks like this:

rxvt|rxvt terminal emulator:\
        :am:km:mi:ms:xn:xo:\
        :co#80:it#8:li#65:\
        :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
        :LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:\
        :cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\
        :cs=\E[%i%d;%dr:ct=\E[3k:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:\
        :ho=\E[H:ic=\E[@:im=\E[4h:\
        :is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\
        :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\
        :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kI=\E[2~:\
        :kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:ke=\E[?1l\E>:kh=\E[H:\
        :kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:\
        :me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:\
        :so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:\
        :ue=\E[m:up=\E[A:us=\E[4m:

I have noticed, though, that if I type the command echo $TERM in an rxvt window the result is xterm-color, so perhaps the above rxvt termcap entry isn't being used at all.

I'd love to know if anyone else has any luck transplanting either or both of these two changes into their system. The rxvt termcap entry can be pasted right into your /etc/termcap file; in mine it is right after the xterm stanzas. I don't believe the order of stanzas is important, though.

After using linux for a while you tend to take for granted the supple flexibility inherent in the Linux manner of dealing with files, partitions, and mount-points. Recently I began to feel constrained by a relatively small /usr partition, so I thought I'd do some experimenting.

I happened to have an unused 100 mb. partition on my disk, so I created an ext-2 filesystem on it and mounted it on an empty directory, /new, created for this purpose. Then I ran this command: cp -a /usr/X11R6 /new. Using cp with the -a switch is really handy, as it copies all subdirectories, links, and files, and also saves permissions.

The next step was modifying the /etc/fstab file, inserting the following entry which causes /usr/X11R6 to be mounted on the new partition:

         /dev/hda11     /usr/X11R6   ext2     defaults   1   2

Before rebooting I dropped back to a console and deleted the entire contents of the /usr/X11R6 directory.

I was reasonably certain this would work, but I must confess I was surprised when (after rebooting) X started up without comment, as if nothing had changed.

Linux doesn't really care, after all, where files are located, as long as there is a congruence between the partition table and the contents of the /etc/fstab file. One benefit of this laxity is that repartitioning (with all of the attendant backing up, restoring, etc.) should seldom be necessary.