[olug] .bash_profile and runlevels

Christopher Cashell topher at zyp.org
Thu Jun 26 19:08:10 UTC 2003


At Thu, 26 Jun 03, Unidentified Flying Banana Ryan O'Rourke, said:
> > using .bash_profile
> > wouldn't be the best place to put this.  You'd want to put it in
> > $HOME/.xsession[1].
> 
> Unfortunately on my RedHat 8.0 box the only thing I can find about
> xsessions is /etc/X11/xdm/Xsession and /etc/kde/kdm/Xsession. 
> These don't look quite right, but google did find an example .xsession
> here:
> http://www.linuxgazette.com/issue49/bennet.html#homexcess

Ahhh, I see.  I just glanced at the example file I originally
referenced, and I recognize the author's name as a Debian Developer, and
one of the Debian X Windows maintainers.  I can only assume that he
contributed the documentation, but that it isn't included in X Windows
itself.

My apologies for not checking that closer.

> It looks like a .xsession file could be something as simple as this:
> [root at ryano ryano]# cat /home/ryano/.xsession
> #!/bin/bash
> galeon &

Yep, you are correct.  I've gone ahead and attached the text
documentation file I was referencing to this e-mail, in case anyone is
interested in using .xsession files.

> Thanks for the pointer, Christopher. I'll keep it mind for other
> applications.
> I actually found a different solution to this problem:
> Control Center --> Extras --> Sessions
> and added my Wine process to the "Startup Programs" tab with a priority
> of 70 so it runs after everything else.

Ahh, cool.  Do you know off hand if that's a Red Hat specific thing, or
if it's a Gnome thing, or what?  I seem to remember someone mentioning
something like that for Gnome to me at one point, but I don't use Gnome
or KDE frequently enough to remember all their details.

> I was just so used to manually configuring these types of things in
> files that it didn't even cross my mind that RedHat might have a
> "Windows way" of doing the same thing as the Startup Folder :-)

Yet another example of how Linux's ease of use constantly improves. ;-)

> Thanks again!
> 
> -- Ryan

-- 
| Christopher
+------------------------------------------------+
| A: No.                                         |
| Q: Should I include quotations after my reply? |
+------------------------------------------------+

-------------- next part --------------
#!/bin/sh

# Sample .xsession file, by Branden Robinson
# This file is in the public domain.
# To use this file:
#    cp -i /usr/share/doc/xfree86-common/examples/xsession $HOME/.xsession

# Users are strongly encouraged to edit this file to their tastes.

# Note that the $HOME/.xsession file only has effect if the
# "allow-user-xsession" option is set in /etc/X11/Xsession.options.  See
# Xsession.options(5) for more information ("man 5 Xsession.options").

# NOTE: This example file assumes that the xbase-clients, xterm, and twm
# packages are installed.  If they are not, the commands that reference them
# will fail.  In the case of twm (see below), this will cause the script to
# exit and the X session to end almost as soon as it begins.

# The X session file, in this case $HOME/.xsession, is a shell script that
# contains a list of things to do (programs to run and so forth) every time
# X starts for a particular user.  It allows you to personalize your X
# environment and get down to business (or play) faster.  If there are
# things you want done every time you start X (or log into a machine using
# XDM), rather than doing them by hand every time by running commands from
# a terminal window, you can place them here, in the .xsession file, and
# they will be run automatically, every time.

# There are essentially three types of commands in an .xsession file; we
# usually fire up some persistent X clients, like xterms, a clock, a biff
# program of some sort, etc., which we expect to stick around more or less
# for the duration of our X session.  These commands will need to be
# backgrounded, or "amped off", otherwise your X session will "stay" on
# that command until it exits.  The second type of command is relatively
# instantaneous in effect, or we *desire* the X sesson to stop until that
# command exits -- we don't background those.  Finally, at the end of our
# .xsession file we generally "exec" a window manager.  That replaces the
# running .xsession shell script with the window manager process, and when
# the window manager exits, the X session is over (the user returns to the
# virtual console or the XDM login screen).

# Before starting, I should mention that all of the commands used in this
# example have manual pages ("man xclock", for instance) and reading those
# will help you a long way towards getting things tweaked just the way you
# like them.

# You should ensure that any variables that you reference in this file are
# defined.  Generally, for sessions started with startx this is not necessary,
# because startx itself is run from a shell prompt, so the shell's startup
# files (like .profile and .bashrc for bash, or .login and .cshrc for csh
# and tcsh) have already been run.  But for X sessions started by xdm, these
# startup files are not run (which makes sense, because xdm is not a shell),
# and this shell script is not run in an environment with those variables
# available.  The best way to handle both of these cases is with a structure
# like the following:
#
# [ "$MYVARIABLE" ] || MYVARIABLE=value
#
# The above command only sets MYVARIABLE to value if MYVARIABLE is not defined
# (or null).  See the manual pages for bash(1) and [(1) (that's right, there
# is a command called left-bracket -- pronounced "test") and/or a good book on
# Unix shell programming for more information.

# For our first real command, let's have a one that is not backgrounded; we'll
# show the system's message of the day with the xmessage command (which is in
# the xcontrib package).  This may be very useful on multi-user machines where
# the /etc/motd file is actually used for announcements; it may be less useful
# on a personal computer that is minimally shared.  If we amped this off,
# then the message box would come up and execution would proceed (in other
# words, the remaining commands in this .xsession script will go ahead and
# execute while the xmessage window in still on the screen).  Without being
# backgrounded, this sort of forces an acknowledgement of the message before
# proceeding, but has a timeout of sixty seconds, after which the message will
# dismiss itself, in case the machine is slow and the user has wandered
# off just after logging in (if it takes a while to start the remaining X
# clients, he'll probably want to come back with them up and running).
xmessage -nearmouse -file /etc/motd -timeout 60 -button Continue

# The following command simply sets the screen background (often called the
# "desktop" in other winodwing systems, but in X the proper term is "root
# window") to blue, and has relatively instantaneous effect.  We could amp it
# off, but that would be pretty pointless, since this command takes almost no
# time to run.  If you have something else that will do something with the
# root window (xloadimage, floatbg, xearth, etc.), you'll probably want to
# comment out or delete the next line.
xsetroot -solid skyblue

# Let's get a little load average action going...
# It is important to learn how the geometry option/resource works -- the first
# two numbers are the dimensions (width and height, in pixels), and the next
# two are position parameters as offsets from the edges of the screen.  See
# the X manpage ("man X"), section "GEOMETRY SPECIFICATIONS" for more
# information.
xload -bg black -fg green -hl red -update 5 -geometry 170x100+70+0 &

# Something to check the mail...
xbiff -bg black -fg green -geometry 100x50+255+0 &

# Something to keep track of time...
xclock -bg black -fg green -update 1 -digital -geometry 150x40-0+0 &

# And finally, the most important part of any GUI, the command-line interface.
# Note that for xterm the geometry dimensions are expressed in character
# cells, not pixels (e.g., 80x24).
xterm -title "Debian GNU/Linux" -ls -geometry 80x24+70+135 &

# Now execute the window manager and we'll be on our way.  Most people have
# window managers they like better than twm -- install the corresponding
# Debian package and edit the following line appropriately if you're one of
# them.
exec twm


More information about the OLUG mailing list