[SOLVED] Sourcing dotfiles.

eloi · 05-02-2014, 07:42 AM

It makes me happy to say Didier is right.

@Lockywolf, I think you're wrong in your approach.

An OS maintainer should not assume you need to put *nothing* at time to create new users in the system. If you, like a system administrator, judge that the users in the systems you manage need some help add what you want to /etc/skel.

Each user should read the respective man pages and edit his environment in his respective home dir. You don't know what variables are setted and how they are setted by default on each OS (it depends of how wrong the OS maintainer is about adding default friendliness). The more variables you override in your home dir the more your software will do what you want and the more portable your environment will be touching the less as possible the system defaults.

Use the default shell on each OS. On FreeBSD csh, ksh on OpenBSD and bash on Linux. Some people think that using the Friendly Fully Featured Desktop Environment - the default shell on MSWindows - makes them look younger, that's not true. If you value your time edit your own .xinitrc, your .Xdefaults, your .fonts.conf, etc. and run a window manager using xinit. I mean, if you use Xfce all the good advices you was given here could be useful today but not tomorrow; it's the slight difference between to digest and to accumulate.

Like you was told, for bash just source .bashrc from .bash_profile.

David Vincent
Architect

Lockywolf · 05-02-2014, 08:55 AM

Quote:

It makes me happy to say Didier is right.

He basically is totally wrong.

Moreover, he doesn't even understand the issue.

Slackware _already_ sets up preferences for default login shells.
Moreover, in a totally "unslacky" way, it even has the following switch in the /etc/profile

Code:

# Set a default shell prompt:
#PS1='`hostname`:`pwd`# '
if [ "$SHELL" = "/bin/pdksh" ]; then
 PS1='! $ '
elif [ "$SHELL" = "/bin/ksh" ]; then
 PS1='! ${PWD/#$HOME/~}$ '
elif [ "$SHELL" = "/bin/zsh" ]; then
 PS1='%n@%m:%~%# '
elif [ "$SHELL" = "/bin/ash" ]; then
 PS1='$ '
else
 PS1='\u@\h:\w\$ '
fi
PS2='> '
export PATH DISPLAY LESS TERM PS1 PS2

On which GazL had this topic:
http://www.linuxquestions.org/questi...ts-4175472234/

So, apparently, setting reasonable defaults in no way violates Slackware's policy. And it has nothing to do with "modifying" software, as "/etc/profile" has no connection to any of the shell packages.

Please, reread this post attentively:
http://www.linuxquestions.org/questi...5/#post5163217

Quote:

An OS maintainer should not assume you need to put *nothing* at time to create new users in the system.

The question has nothing to do with an OS maintainer. I am asking to explain unexpected behaviour (not inheriting env) and and advice how to tune _my_ concrete machine to set up non-login shells reasonably in a system-wide manner in a resilient way.

GazL · 05-02-2014, 09:20 AM

The PS1 and PS2 are exported by default as you say, so they will be inherited by descendants of the startx. If they're not present when it gets to xterm/bash then something in the inheritance chain must be unsetting them. What is doing it likely depends on which environment you're using, and how you're starting xterm. XFCE startup for example is particularly tortuous, and all that dbus-launch stuff that some of the xinitrc's use probably isn't helping matters either.

As for the second question, the way bash separates .bashrc and .profile makes this particularly difficult, as it simply doesn't support a global to all users bashrc file.

About the only thing I could come up with (other than the stuff in the discussion I have already mentioned - which as you say relies on per-user dot files) would be to move bash out of the way, and make bash a wrapper around the real bash such as:

Code:

#!/bin/sh
exec /usr/bin/real_bash --rcfile /etc/bashrc "$@"

... and then have /etc/bashrc run the users ~.bashrc at the end, but that's a pretty ugly solution, and it's not something I'd particularly recommend doing.

You could always change all your users to a different shell such as ksh that has a reasonable initialisation procedure and avoid the issue. The problem here is simply that bash's startup is badly designed, and any workaround is going to be somewhat of a kludge.

eloi · 05-02-2014, 09:50 AM

Quote:

Originally Posted by Lockywolf

He basically is totally wrong.

Moreover, he doesn't even understand the issue.

Slackware _already_ sets up preferences for default login shells.
Moreover, in a totally "unslacky" way, it even has the following switch in the /etc/profile

First of all, I am not a "Slacker" (I mean a fanatic). Slackware has more things configured by default than I'd like. Besides /etc/profile take a look to /etc/profile.d/ content.

Anyway, all systems has a minimal default configuration in /etc/profile. What Slackware doesn't do is to add stuff in your home dir (from /etc/skel).

Quote:

The question has nothing to do with an OS maintainer.

Since you want to modify the system wide configuration...

Quote:

I am asking to explain unexpected behaviour (not inheriting env) and and advice how to tune _my_ concrete machine to set up non-login shells reasonably in a system-wide manner in a resilient way.

Perhaps I didn't understand what you said here:

Quote:

The second question is, how do I make my XTERM-interactive non-login shells have the same friendliness as login shells, without modifying any per-user properties (like editing dotfiles in the user dir or making terminal emulators start login shells). Basically, the system must be resilient enough so that if a user wipes out all his homedir (due to stupidity or malware), he still would receive a fine-tuned shell with bash-completion and stuff. (thus editing skel-files is also not a very good option)

I'd already read gazL posts and understood his point.

Lockywolf · 05-03-2014, 11:12 AM

I continue debugging this issue. I added debug print to the startx script, and indeed, PS1 gets cleared on the very entrance to startx.

Basically, what I do:

Code:

PS1=\u@\h:\w\$
startx-begin-start
whoami:lockywolf
PS1=
startx-begin-end
startx-end-start
whoami:lockywolf
PS1=
startx-end-end

This is a logfile.

The first line is added manually with

[code]
echo PS1=$PS1 >> varlog.log

and the rest is generated by the following lines added to the startx:

Code:

#Debug:
echo startx-end-start >> /tmp/vardebug.log
echo whoami:`whoami` >> /tmp/vardebug.log
#echo envPS1=`env | grep PS1` >> /tmp/vardebug.log
#echo shellPS1=`set | grep PS1` >> /tmp/vardebug.log
echo PS1=$PS1 >> /tmp/vardebug.log
echo startx-end-end >> /tmp/vardebug.log
#Debug-end

This is where I get lost.

PS1 is an env variable (not shell).
Why isn't it inherited by the closest child process? (startx)

Lockywolf · 05-03-2014, 11:29 AM

Asked myself, answered myself:

http://superuser.com/questions/66306...d-variable-ps1

Quote:

PS1 is the only variable not propagated by bash to it's non-interactive children.

Why? Because bash thinks this way is better. Stupid bash.

The solution to the second problem awaits to be found.

saulgoode · 05-03-2014, 12:54 PM

Quote:

Originally Posted by Lockywolf

Why? Because bash thinks this way is better. Stupid bash.

PS1 being set signals to the child process that it is being executed interactively. In some distributions, PS1 is tested in .bash_profile to, for example, avoid producing messages with non-interactive logins (such as ones initiated by 'scp').

Lockywolf · 05-04-2014, 04:46 AM

Wasted a couple of hours trying to embed login shell recognition into $ENV.

Any suggestions on that?

I am trying to do something like that:

Code:

ENV = "\`if [ shopt -o login_shell ]; then x="/etc/profile"; else x="/etc/sh.shrc"; fi \`"

Richard Cranium · 05-04-2014, 03:47 PM

Quote:

Originally Posted by Lockywolf

Wasted a couple of hours trying to embed login shell recognition into $ENV.

Any suggestions on that?

I am trying to do something like that:

Code:

ENV = "\`if [ shopt -o login_shell ]; then x="/etc/profile"; else x="/etc/sh.shrc"; fi \`"

What do you want to be in ENV when this executes? Or maybe better: what do you intend to do with ENV?

Lockywolf · 05-04-2014, 04:00 PM

Quote:

What do you want to be in ENV when this executes? Or maybe better: what do you intend to do with ENV?

Well, I do not know exactly how ENV expands, but I the shell doing something like:

Code:

source $ENV

Thus after ENV expands I want to get something like:

Code:

source `if [ shopt -o login_shell ]; then x="/etc/profile"; else x="/etc/sh.shrc"; fi \`

Further expanding to:

Code:

source /etc/profile

or

Code:

source /etc/sh.shrc

That would be the ultimate solution.
As long as the shell is /bin/sh (posix-mode), it would perform different (appropriate) inits depending on it being login or non-login.

Richard Cranium · 05-04-2014, 04:49 PM

Well, if you replace "x=" with "echo " in the above, you'll be a little closer to what you want.

How about:

Code:

burp () { if [ shopt -o login_shell ]; then echo "/etc/profile"; else echo "/etc/sh.shrc"; fi }

then you can simply use

Code:

source `burp`

or

Code:

source $( burp )

?

Lockywolf · 05-05-2014, 10:25 AM

Eventually I came up with the following solution:

I consider it rather ugly, so if anyone has better ideas: welcome.

1)Add the following line to '/etc/profile':

Code:

ENV=/etc/sh.detector
export ENV

2)Write the following '/etc/sh.detector':

Code:

#!/bin/sh
shopt -q login_shell
lsh=$?

mainconfig () { if [ $lsh -eq 0 ]; then echo "/etc/profile"; else echo "/etc/sh.shrc"; fi }
userconfig () { if [ $lsh -eq 0 ]; then echo "~/.profile"; else echo "~/.shrc"; fi }

if [ $lsh -eq 0  ];
then
    if [ -x $(userconfig) ]; then  source $( userconfig ); fi;
else
    if [ -x $(mainconfig) ]; then  source $( mainconfig ); fi
    if [ -x $(userconfig) ]; then  source $( userconfig ); fi
fi

3)Add '/bin/sh' to '/etc/shells'
(Why isn't it there already?)

4)chsh to '/bin/sh'

5)As a starting point, create the following '/etc/sh.shrc':

Code:

#!/bin/sh

source /etc/profile

6)Customize '/etc/sh.shrc'

The thing I dislike most here is the double redefinition of ENV.

Please, give your comments, I would really like to read them.

Note that this modification seems to be the least intrusive, as all behaviour remains the same save the appearance of a single new entity in '/etc/shells', which (apart from being posixly correct), behaves in a user-friendly way.

UPD:It might be a better option to create a separate posix.sh inside /etc/profile.d/ to make this totally independent of the base system.

UPD2:For some reason, when sh is executed with '--login', it executes /etc/profile, and then executes $ENV.
Strange.

GazL · 05-06-2014, 06:53 AM

When you start a posix 'login' shell it will run /etc/profile, then ~/.profile, and then whatever is pointed to by $ENV when it gets to the end of ~/.profile.

When you start a posix non-login shell it will run whatever is pointed to by $ENV when the shell was started.

The solution is to put anything that you need to be configured by both types of shell in the file that you point to in $ENV and then make sure that ENV is set (either from the inherited environment, or by being set for the current shell in /etc/profile or a profile.d/ member if your /etc/profile supports those.

You never want to be sourcing /etc/profile from the script pointed to by $ENV. It's just completely the wrong thing to do.