Re: Trying to use /bin/sh
On Sep 28, 2013, at 12:41 PM, Matthew D. Fuller wrote: > On Sat, Sep 28, 2013 at 04:36:03PM + I heard the voice of > Teske, Devin, and lo! it spake thus: >> >> xterm -sb -sl 400 -ls -r -si -sk -fn "-misc-fixed-medium-r-*-*-15-*" > ^^^ > For those with variable-width fonts in their Mail Reader... He highlighted "-ls" which stands for "login shell"; xterm(1). > being the operative bit. Or setting loginShell in resources; that way > you don't have to change any invocations anywhere. > Hadn't realized you could do that... excellent! Thanks for the tip on setting that as a resource. -- 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"
Re: Trying to use /bin/sh
On Sat, Sep 28, 2013 at 04:36:03PM + I heard the voice of Teske, Devin, and lo! it spake thus: > > xterm -sb -sl 400 -ls -r -si -sk -fn "-misc-fixed-medium-r-*-*-15-*" ^^^ being the operative bit. Or setting loginShell in resources; that way you don't have to change any invocations anywhere. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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"
Re: Trying to use /bin/sh
On Sat, 2013-09-28 at 16:36 +, Teske, Devin wrote:
> 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.
For bash the solution I've been using for like 15 years is that
my .bash_profile (used only for a login) contains simply:
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
And everything goes into .bashrc which runs on non-login shell
invocation. I have a few lines of code in .bashrc that have to cope
with things like not blindly adding something to PATH that's already
there[1] but other than that I generally want all the same things to
happen whether its a login shell or not.
I think the bourne-shell equivelent is to have a .profile that just sets
ENV=~/.shrc or similar. (I think someone mentioned that earlier in the
thread.)
[1] for example:
if [[ "$PATH" != *$HOME/bin* && -d $HOME/bin ]] ; then
export PATH=$HOME/bin:$PATH
fi
-- Ian
___
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"
Re: Trying to use /bin/sh
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"
Re: Trying to use /bin/sh
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. Regards, STefan ___ 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"
Re: Trying to use /bin/sh
On Fri, Sep 27, 2013 at 12:20:32PM -0700, Sean Bruno wrote: > I was attempting to simply set my EDITOR env variable for use on my > system today and discovered that I do *not* understand how computers > work. > After realizing that I simply do not understand what's going on, I broke > down and put an "echo test" into /etc/profile and ~/.profile. > I can't see why, but logging in via xdm/xfce4 isn't doing any of the > normal login things and nothing in my .profile is ever executed by any > shell, ever. > None of these get executed unless its a login shell. xfce4 doesn't seem > to pick these up when starting up, so I have no idea what to do. > For now, I've put the needed things into a .bashrc and switched my > loging shell to bash, which is not really what I wanted to do. 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. A different direction is to accept that the environment variables in the X session will be incorrect and make all xterms start login shells (e.g. xterm -ls). You may also be able to use setenv in ~/.login_conf. -- Jilles Tjoelker ___ 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"
