On Sep 28, 2013, at 1:12 AM, Stefan Esser wrote:
> Am 28.09.2013 00:14, schrieb Jilles Tjoelker:
>> sh's model of startup files (only login shells use startup files with
>> fixed names, other interactive shells only use $ENV) assumes that every
>> session will load /etc/profile and ~/.profile at some point. This
>> includes graphical sessions. The ENV file typically contains only shell
>> options, aliases, function definitions and unexported variables but no
>> environment variables.
>>
>> Some graphical environments actually source shell startup files like
>> ~/.profile when logging in. I remember this from CDE for example. It is
>> important to have some rule where this should happen to avoid doing it
>> twice or never in "strange" configurations. As a workaround, I made
>> ~/.xsession a script interpreted by my login shell and source some
>> startup files. A problem here is that different login shells have
>> incompatible startup files.
>
> I used to modify Xsession to do the final exec with a forced login
> shell of the user. This worked for users of all shells.
>
> The script identified the shell to use and then used argv0 to start
> a "login shell" to execute the display manager.
>
> A simplified version of my Xsession script is:
>
> ------------------------------------------------------------------
> #!/bin/sh
>
> LIB=/usr/local/lib
>
> SH=$SHELL
> [ -n "$SH" ] || SH="/bin/sh"
> SHNAME=`basename $SH`
>
> echo "exec $LIB/xdm/Xsession.real $*" | \
> /usr/local/bin/argv0 $SH -$SHNAME
> ------------------------------------------------------------------
>
> The argv0 command is part of "sysutils/ucspi-tcp", BTW.
>
> This script prepends a "-" to the name of the shell that is
> started to execute the real "Xsession", which had been renamed
> to Xession.real.
>
> I know that the script could be further simplified by using "modern"
> variable expansion/substitution commands, but this script was in use
> some 25 years ago on a variety of Unix systems (SunOS, Ultrix, HP-UX)
> and I only used the minimal set of Bourne Shell facilities, then.
>
> You may want a command to source standard profiles or environment
> settings before the final exec, in case the users shell does not
> load them.
>
In my ~/.fvwm2rc file, this is how I launch an XTerm. This achieves the
goal of sourcing my profile scripts like a normal login shell while launching
XTerm(s) in the GUI.
DestroyFunc FvwmXTerm
AddToFunc FvwmXTerm
PipeRead '\
cmd="/usr/bin/xterm"; \
[ -x "${cmd}" ] || cmd="/usr/X11R6/bin/xterm"; \
[ -x "${cmd}" ] || cmd="xterm"; \
cmd="${cmd} -sb -sl 400"; \
cmd="${cmd} -ls"; \
cmd="${cmd} -r -si -sk"; \
cmd="${cmd} -fn \\"-misc-fixed-medium-r-*-*-15-*\\""; \
echo "+ I Exec exec ${cmd}"'
Essentially producing an XTerm invocation of:
xterm -sb -sl 400 -ls -r -si -sk -fn "-misc-fixed-medium-r-*-*-15-*"
And everytime I launch an XTerm with that, I get my custom prompt set
by ~/.bash_profile.
Of course, I'm also a TCSH user, so when I flop over to tcsh, I also get
my custom prompt set by ~/.tcshrc
But failing that... you could actually make your XTerm a login shell with:
xterm -e login
But of course, then you're looking at having to enter credentials.
Perhaps it's just a matter of getting your commands into the right file...
.bash_profile for bash and .tcshrc for tcsh.
--
Devin
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
