meyerm@saic.COM (Michael Meyer) (02/14/91)
For those of you who use xdm to manage your display, I direct the following question/problem: When I put any kind of control structures in my $HOME/.xsession file (if-then, case,while, etc.) the script evidently bombs and I am returned to the authentication widget, i.e., left high and dry. If I remove or comment out the "offending" control statements, my session starts up fine. (My .xsession is a Bourne shell script started up by a nearly standard- distribution Xsession file in /usr/lib/X11/xdm by way of the line: exec $HOME/.xsession Note that I have even tried tautological test in my .xsession [if 1=1].) Any ideas ?? Thanks in advance. Please reply to xpert. Michael S. Meyer SAIC San Diego, CA 92121 619-546-6097 meyerm@cpva.saic.com
pete@iris49.UUCP (Pete Ware) (02/15/91)
I'd first make sure your .xsession works at all. My second guess is
that your shell script is getting executing by the csh because:
1. The first character is a '#'. Change it to "#! /bin/sh"
2. xdm is doing something like "/bin/csh -c $HOME/.xsession"
and it's getting read as a csh script.
To test your script, rename the .xsession file to something innocuous
and start up with the default configuration. Then just type
"$HOME/.xsession" and see if everything works.
--pete
P.S. Granted your tautological test [if 1=1] is probably just a
typo, but it won't work under any shell.
Pete Ware / Biosym / San Diego CA / (619) 546-5532
uucp: scripps.edu!bioc1!pete
Internet: bioc1!pete@scripps.edudws@margay.cs.wisc.edu (DaviD W. Sanderson) (02/16/91)
In article <9102141614.AA03702@iris49.biosym.com> pete@iris49.UUCP (Pete Ware) writes: >My second guess is that your shell script is getting executing by the >csh because: [...] > 2. xdm is doing something like "/bin/csh -c $HOME/.xsession" > and it's getting read as a csh script. You can see exactly how it's being run by finding the xdm configuration files. For instance, on my workstation the script that xdm runs is /usr/misc/X11/lib/xdm/Xsession. Down towards the end it checks if there is a $HOME/.xsession file and if so, does this: exec /bin/csh $HOME/.xsession In order to get around this problem, I devised the following prologue for my .xsession file that may come in handy for others, too. ---------------------------------------------------------------------- #!/bin/sh #------- # .xsession prologue # # This prologue makes sure the subsequent code is run in sh, or ksh if # it is present. It is written to work in csh, sh, and ksh. Specific # pathnames may have to be altered (or added) if your ksh isn't in /bin. # # This prologue is needed since in some installations the .xsession file # is forcibly run with csh or sh. # # DaviD W. Sanderson 15 Feb 1991 (dws@cs.wisc.edu) #------- #------- # If the script is now being executed by csh, look for ksh and try to # exec it. Otherwise exec sh. Note that test -x cannot be used since # some versions of test do not support the -x option. :-( # # The method used is to look for variables that should only be set in # csh. This is not perfectly bulletproof, but works well enough for me. #------- test "$cwd" != "" && test -f /bin/ksh && exec /bin/ksh $0 $argv:q test "$cwd" != "" && exec /bin/sh $0 $argv:q #------- # At this point the script is being executed by either sh or ksh. # # We might have gotten here from sh in the first place (if perhaps the # .xsession was forcibly run with sh), so see if we are in sh. # If we are, then see if ksh exists and exec it if it does. # # The method used is to look for ~ expansion. No ~ expansion means sh. #------- test "~" = ~ && test -f /bin/ksh && exec /bin/ksh $0 ${1+"$@"} #------- # At this point the script is being executed by ksh if it is available, # otherwise sh. #------- # [local configuration] ---------------------------------------------------------------------- -- ___ / __\ U N S H I N E DaviD W. Sanderson | | | I N E dws@cs.wisc.edu _____| | |_____ ________ \ / \ |__/ /////__ Fusion Powered Locomotives Made to Order \____/ \__|_/ \\\\\______ (TARDIS model available at extra cost)
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (02/20/91)
meyerm@saic.COM (Michael Meyer) writes: >For those of you who use xdm to manage your display, I direct the following >question/problem: I am one of those so I will try to answer. >When I put any kind of control structures in my $HOME/.xsession file (if-then, >case,while, etc.) the script evidently bombs and I am returned to the >authentication widget, i.e., left high and dry. If I remove or comment out >the "offending" control statements, my session starts up fine. Obviously there is some sort of script/interpreter mismatch as some of the other response seem to indicate. I do quite a deal of complex processing to initiate my X session and so I have modularized it as much as I can. What I do in my .xsession is to just start up two other processes in the background (as GRANDchildren to avoid defunct processes) and then run xlogo. By running xlogo as the descendant from xdm, I have specific control over when to terminate my X session. Thus I can choose to terminate any or all other clients, including my window manager, any time I choose, without terminating the X session (though some could get me in a situation where I can't start anything new). While the above describes the gist of my .xsession, it also does a lot of other things to take care of numerous petty details. It allows me to even start up my X session from another terminal should xdm not be talking to me (it has a nasty habit of giving up if it cannot contact my X server right when it starts). Here is my .xsession file. I use csh as the interpreter here. #!/bin/csh -f # .xsession .start/xsession # # This .xsession shell script establishes a dummy process as the # process that descends from xdm to allow all other processes to be # terminated as desired without causing the entire X session to be # terminated when xdm grabs the server. # Final X session termination requires terminating the dummy process. # # The .xmanager shell script is run in the background to setup the # window manager for the X session configuration. # The .xprofile shell script is run in the background to setup the # general X session configuration and the first windows. # # This script may be started by means other than xdm if needed. # The first argument is the display to override. #------- # make sure we are in home directory # establish command path #------- cd if ( -r .start/csh.path ) source .start/csh.path #------- # if no DISPLAY is specified and none is established use the default # if one is specified, use the one specified in the first argument #------- if ( $1 == '' ) then if ( $?DISPLAY == 0 ) then setenv DISPLAY `cat .xdisplay` endif else setenv DISPLAY $1 endif #------- # identify log file and pid files per display #------- set log = .log/xsession set logd = .log/xsession.$DISPLAY set pid = .log/pid.xchild.$DISPLAY #------- # get date only once #------- set d = `date` #------- # make sure log files exist #------- if ( ! -f $log ) then echo > $log endif if ( ! -f $logd ) then echo > $logd endif #------- # log the starting of the general X session setup script #------- echo Begin .xsession on $d on $DISPLAY >> $log echo Begin .xsession on $d >> $logd #------- # start up the background scripts # each is run as a grandchild to avoid becoming defunct # since this process will not end (defers xdm) and thus # will not wait for any child processes. #------- ( .xmanager & ) < /dev/null >>& $logd ( .xprofile & ) < /dev/null >>& $logd #------- # record the process id the dummy process will be running in #------- echo $$ >! $pid #------- # execute the xdm child process #------- exec xlogo -display $DISPLAY -geometry 22x22-12-12 < /dev/null >& /dev/null -- --Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society <phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.
schoch@sheba.arc.nasa.gov (Steve Schoch) (02/22/91)
Instead of xlogo, there is a program made for this purpose called xlogout. Xlogout just sits there until its only Command widget button is pressed. The advantage is that you can reset the display and logout even if you happen to kill the window manager and exit from all xterms. Steve