|
|
||
Useful Shell Scripts© Copyright Darrell Anderson. (Autumn 2008) When I realize I am continually repeating various computer related tasks, I start to ponder ways to automate those events. Such was the case recently when the Slackware change log informed me that yet another version of Firefox was available. Along with these updates I have learned that I probably should concurrently update to the latest version of the NoScript extension too. Updating Firefox and NoScriptIn Slackware the usual method of updating packages is to run the upgradepkg script. I use that tool to update Firefox, but for me there always is some subsequent manual tinkering. Although most people save various search plugins and extensions in the profile directory located in their home directory, I prefer to keep those files stored globally and therefore available regardless of which account I login under. Further, I have modified the browser.xul file found in the Firefox chrome directory to allow me to use Ctrl-Q as the keyboard method of closing Firefox. The default hotkey combination of Alt-F4 makes sense in the Windows world, but in GNU/Linux Ctrl-Q is more common, at least with the keyboard layout I use in KDE. Not having Ctrl-Q available frustrated me until the day I modified the browser.xul file. Updating Firefox deletes that menu and keyboard change in that file. I have to manually restore my version of the file. Easy to perform but always repetitive and inconvenient. I also do not like the way any Firefox updating replaces the default search plugins. I have modified some of the default search plugins. I keep a backup copy of the directory. When I finish updating Firefox I merely overwrite the default settings to those I prefer with my files. Another aspect about updating Firefox that always rankles me is when I first start the new version. During that very first session Firefox always connects to the Mozilla home web site. I hate pompous developers who act like that. The reason Firefox automatically connects to the Mozilla home site is in the prefs.js file. There are two preference options reflecting the previous version of Firefox (browser.startup.homepage_override.mstone and extensions.lastAppVersion.). When Firefox starts, these preference options are updated to the new version numbers, but the initial difference is seen by the internal programming as a sign to connect to the Mozilla web site so users can read the latest release notes. This presumptuous ordeal makes some sense for people who have automated updating enabled but I do not. I always manually update my software. I have all automated updating preferences disabled. I call this type of event hijacking although some people would accuse me of stretching the meaning of the word. Nonetheless, any time a browser takes me to a web page I did not request I consider my browser session as being hijacked. This hijacking can be stopped if, after updating and before starting Firefox, a user manually edits pref.js (and user.js if necessary) to the new version numbers. My new shell script now automates all of these tasks for me. The script does the following:
Because I tend to update the NoScript extension concurrently when I update Firefox, I wrote another shell script to perform similar functions. And the NoScript developers perform the same presumptive hijacking of my browser. So again I modify my prefs.js and user.js to the latest NoScript version number before starting Firefox. The scripts work wonderfully. My browser is no longer hijacked. Switching X Video DriversYet I seemed to be on a script writing roll that day. I maintain various xorg.conf files so I can test other drivers or bail out effortlessly if I botch an xorg.conf modification or driver update. Specifically, I use the proprietary nvidia drivers and I like to keep the generic nv drivers available. I also like to keep the vesa drivers handy. I keep these extra xorg.conf files in the same /etc/X11 directory: xorg.conf Some of the files are for my other computers. I keep the files centrally stored for archival and comparison purposes. Here is my basic approach to creating these files:
I then have an xorg.conf for both nvidia proprietary and the generic nv drivers. I installed the proprietary nvidia drivers using a build script from slackbuilds.org. Included in that package is a shell script that helps users swap driver libraries for the respective driver being used. Basically the script links or unlinks various nvidia-specific library files. My challenge is I tend to be forgetful about some things. When I toggle to the nv version of xorg.conf, I sometimes forget to run the nvidia-switch script. That tends to create various error messages and issues with the nv driver. Conversely, when I revert to the nvidia xorg.conf file, I tend to forget to again run nvidia-switch. Then too, I repeatedly had to manually copy xorg.conf files and vice-versa when I was done testing. I wanted a way to perform this in one smooth move and overcome my forgetfulness. At this point, if I run the nvidia-switch shell script, that script only ensures the correct libraries are available. I manually have to change xorg.conf to the appropriate file. For example, if I run nvidia-switch --nvidia, then before starting X I have to perform the following: cp /etc/X11/xorg.conf.nvidia /etc/X11/xorg.conf If I run nvidia-switch --xorg, then before starting X I have to perform the following: cp /etc/X11/xorg.conf.nv /etc/X11/xorg.conf As is the usual trick with ’nix systems, to automate the task I created a shell script called xorg-switch, through which I also run the nvidia-switch script. Now my conversions from one driver to another is painless and always correct. Shell scripts are powerful and useful. I cannot imagine now trying to run a computer without them. Of course, there are other languages too, such as perl and python, which someday I hope to learn more. Files: Finis. |
||