|
|
||
Bash—Day 27© Copyright Darrell Anderson. I’ve consumed more time with another side-trip. This time learning how to configure bash. Proponents and the priesthood often quip that one cannot survive well in GNU/Linux without mastering some basics of the command line. I agree pragmatically, but not philosophically. If GNU/Linux is to “dominate the world,” more intuitive tools are necessary. Many computer users today could care less about low-level control and tweaking. Just show them a dialog box and some check boxes and they are happy. I want to see more intuitive tools provided, but for the long run, having some modest knowledge of the command line is important if I hope to maintain my own systems. I wanted to configure my bash environment. I wanted a simple colored prompt. I use the KDE Konsole and my current path is part of the title bar so I don’t need that information in my prompt. In my prompt I want only my user and host name. However, there are several files that can be used to customize a user’s bash environment. My bash environment works fine in my Mandrake 9.2 setup. The Mandrake developers provide nominal scripts and customizing them is a matter of plugging and chugging. Thus, I at least had an idea of what files should exist. Unfortunately, only one of these files exists in the Slackware installation. Yes, I copied my files from Mandrake to Slackware, but things did not work the same way. With a lot of painful surfing and exhaustive testing I finally got things to work. What again frustrates me is the lack of easy-to-find information. I finally had some success when I ran into a document called Beyond Linux From Scratch. There are at least four fundamental files that can customize a bash environment:
There are at least two additional files that many people use:
Within this framework, additional scripts are stored in /etc/profile.d. There is a general convention that seems popular for using these files:
The trick is getting all of these files working together. A key is called sourcing one file from another. Reading the bash man page late at night is not recommended, but those who persevere will learn that the login command automatically calls or sources /etc/profile. Login then looks for (1) ~/.bash_profile, (2) ~/.bash_login, (3) ~/.profile or (4) /etc/bashrc, and in that order. This is an exclusive list. That is, upon the first successful find, login stops looking for the other local files. An xterm or console session from within X sources ~/.bashrc and nothing more. The logout command sources ~/.bash_logout. I finally got everything to work using the following plan:
The plan seemed to work. As recommended I entered my global aliases in /etc/bashrc. To /etc/profile I added a source call to /etc/bashrc. Because I am the sole user of this computer, I entered my preferred default bash prompt in /etc/profile. That way, regardless of whether I am a mortal user or a super user I get the same prompt. Personal preference. If later I want a different prompt for root I can edit ~/.bash_profile. For the learning experience, I wanted to use ~/.bash_login and ~/.bash_logout. For ~/.bash_login I added the following: #!/bin/sh#echo "[01;33mHello $USER![00m" For ~/.bash_logout I added: #!/bin/shecho "[01;33mGoodbye $USER![00m" sleep 1 clear Everything worked. At least until in KDE I assigned Ctrl-Alt-Del to System Guard, a similar approach to pressing those keys in Windows to obtain access to the Task Manager. When I tested my keyboard, System Guard started but I received an error message from localhost. The message was the text from my ~/.bash_login script! I suspected a minor bug in System Guard or whatever underlying process being called could not parse escape codes to create color in echo statements. I edited the script and once again started System Guard and no error message. I have no idea why System Guard is calling that script, or what underlying process System Guard is calling that calls that script, but this is an annoying bug. Non-destructive, but annoying. I ended up removing the escape codes from the script. With additional research, later I adjusted how my various files interacted with one another:
This new pecking order seems to stop the System Guard problem. I had some success starting a second GUI session from another terminal console. In Mandrake 9.2, however. I could not get the same process to work in Slackware and I am beginning to wonder if there is something fundamentally configured incorrectly in Slackware. To get the trick to work, one must edit /etc/X11/xdm/Xservers. Yup, another editing tweak for what should be preconfigured or configurable through a GUI tool. However, the K-menu option of “Start New Session” will not appear unless logging in from the GUI login manager. If I log in from the command line and start a second GUI session the KDE menu option does not appear through that route. At least, not for me. An odd design. Slackware still remains a mystery with this option. This is all terribly frustrating and I have no idea why this process is not configured ahead of time at the Slackware offices. This specific feature might not be all-important in migrating, but now has become a mountain that I must climb! The greater mystery to me is that GNU/Linux is supposed to be a multi-user system. Why are such features not automatically enabled and tested? Later I ran across another discussion about editing /etc/kde3/kdm/Xservers. Another discussion referred to editing “the kdm config” file. No such directory exists in Slackware. However, the second reference led me to look in /opt/kde/share/config/kdm. Yes! I had forgotten that there is an additional Xservers file there. I then edited that file. I solved two puzzles in one swoop. I finally had the ability to run a second GUI session when using the KDE login manager and I eliminated those nuisance inet6 error messages from the kdm.log. Or so I thought. Finis. |
||