A More Intelligent startx Script
© Copyright Darrell Anderson.
Introduction
Notice: this How-To is updated for Slackware 12.1 and KDE 3.5.9, although the basics of this essay were used originally with Slackware 10.1 and KDE 3.3.2.
When I first began investigating GNU/Linux I shortly thereafter discovered the wonder and utility of multiple virtual console sessions. I also quickly discovered that starting a new X session was not an intuitive process within those additional console sessions.
When first learning GNU/Linux newbies are instructed to start the X graphical environment by typing startx and away they go. True, to a certain degree. Toggle to one of the additional console sessions and try the same trick and one quickly discovers that startx no longer launches an additional X session. The short answer is that one types startx -- :1.
Of course, without some understanding about GNU/Linux, typing this new cryptic command makes little sense. Most newbies do not understand that startx is a shell script, and that the script option of -- :1 is actually passing parameters to that script. In this case, the :1 parameter is an X server argument to use display number 1 instead of display number 0. The double dash separates X client arguments from X server arguments. This is the kind of syntax only computer geeks appreciate!
To circumvent typing all of this X related gibberish, initially I created a command line alias. For example:
alias startx0="startx -- :0 vt7 -dpi 96 -ac -nolisten tcp 2> /dev/null &"
alias startx1="startx -- :1 vt8 -dpi 96 -ac -nolisten tcp 2> /dev/null &"
With this kind of alias, I need only type startx0 or startx1.
From those beginning days the alias solution was doable, but often I wanted a more sensible way to launch X from the command line — and without all the extra gibberish. However, I needed time to master some fundamentals of GNU/Linux as well as some fundamentals of the shell scripting language. Eventually, however, one day I finally tackled the problem and derived what I call a more “intelligent” startx script.
With this revised script, and the necessary support scripts as well, users never again need try to remember which display option to pass to the startx script. Instead, users merely type startx, regardless of how many X sessions they currently have running. This, to me, is how computers should function to provide a more friendly and usable user interface.
The revised startx script sources a file that the original script references, but to my experience is not widely used — the /etc/xprofile file. I also added several usability echo messages to help inform users what is happening. I then added a status log file, so that users and administrators can investigate problems with starting X.
Combine these revised scripts with some more friendly bash startup scripts, and users need never again feel confused about starting X from the command line. Or, at least, the revised scripts provide a more informative and aesthetic screen for users. I suspect that many veteran command line commandos also will like the revised scripts.
When reviewing the revised startx script, users will first notice that the script sources /etc/xprofile. I merely added several script functions to this file. Reviewers also will notice that I make use of the serverargs parameter within the startx script. I then provide a way to programmatically determine the appropriate virtual terminal number. The remainder of the modifications are largely user-friendly but informative echo messages.
Installation
- Create a backup copy of the affected files to be replaced:
cp -p /usr/X11R6/bin/startx /usr/X11R6/bin/startx.bak
cp -p /etc/xprofile /etc/xprofile.bak - Copy the revised files of the same name to the appropriate location.
- Be sure to chmod 755 startx.
- Be sure to chmod 644 xprofile.
- Copy shell-colors to the /etc directory.
- Be sure to chmod 644 shell-colors.
- Copy local.sh to the /etc/profile.d directory.
- Be sure to chmod 755 local.sh.
Usage
Using the revised scripts is straightforward. From any command line, type startx. The console screen should look like this:
![[Image: Screen capture of startx screen messages.]](../images/startx-1.png)
When exiting X, the console screen should look like this:
![[Image: Screen capture of startx screen messages.]](../images/startx-2.png)
A session log file also will appear in the user’s home directory titled .session-status. In that file will be some useful feedback messages about the X startup process.
In the .session-status log file, an X session started from the command line and startx will look like this:
--------------------------------------------------------
Starting X from startx: 2005-12-20 22:08:45
startx: Using X session DISPLAY :2.
startx: Using virtual terminal vt9.
startx: Use (Ctrl)-Alt-F9 to toggle to this virtual terminal.
startx: Client args: /usr/X11R6/lib/X11/xinit/xinitrc
startx: Server args: /usr/X11R6/bin/X :2 vt9 -ac -nolisten tcp
xinitrc: Launching startkde...
startkde: Starting startkde.
startkde: Starting KDE.
startkde: Shutting down...
startkde: Running shutdown scripts...
startkde: Shutdown complete.
xinitrc: Exiting X: 2005-12-20 22:08:51
startx: Seems everything went okay with this X session!
--------------------------------------------------------
I also use this log file to report other events from scripts I have written. I find this process more sensible rather than clumping all X session messages into the X session error log, which should be reserved only for errors (what a crazy concept, huh?).
Bonus
I modified some KDE files to provide additional consistency. I modified the /opt/kde/share/config/kdm/Xsession file to ensure that the KDE Display Manger (KDM login manager) routes respective session messages to my new .session-status log file rather than to the .xsession-error file. I added some lines just after the Xsession script sources the /etc/xprofile file:
[ -f /etc/xprofile ] && . /etc/xprofile
[ -f $HOME/.xprofile ] && . $HOME/.xprofile
X_Error_Log_Name
Create_Date_String
Initialize_Status_Message KDM
echo "KDM: Starting $1." >> $STATUSFILE
I modified the beginning of the /opt/kde/bin/startkde script as well:
#!/bin/sh
#
# DEFAULT KDE STARTUP SCRIPT ( KDE-3.4.3 )
#
# added the following to help troubleshooting
#STATUSFILE=$HOME/.session-status # created in /etc/profile.d/local.sh
echo "startkde: Starting startkde." >> $STATUSFILE
When X is started from the KDM, the .session-status log file looks like this:
--------------------------------------------------------
Starting X from KDM: 2005-12-20 12:17:06
KDM: Starting /opt/kde/bin/startkde.
startkde: Starting startkde.
startkde: Starting KDE.
startkde: Shutting down...
startkde: Running shutdown scripts...
startkde: Shutdown complete.
--------------------------------------------------------
To remain consistent between starting X from startx or KDM, I added a script function to /etc/xprofile ensuring all X session errors are routed to a file that is named based upon the display session variable: .xsession-errors-:n, where n is the X display number. This modification necessarily requires manually editing /opt/kde/share/config/kdm/kdmrc to ensure that the KDM routes those messages to the same location. The appropriate line to edit:
[X-*-Core]
ClientLogFile=.xsession-errors-%s
Conclusion
Perhaps one day these minor improvements will work their way into mainstream distros and newbies no longer will have to confront the mysterious user-hostile syntax of using the startx script. I hope these efforts help you!
Notice: I never have resolved all the ways to programmatically determine the virtual display number and I welcome suggestions that will improve this section of the script.
Source Files
Finis.