Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
05-02-2014, 07:42 AM
|
#16
|
Member
Registered: Nov 2010
Posts: 227
Rep:
|
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
|
|
|
05-02-2014, 08:55 AM
|
#17
|
Member
Registered: Jul 2007
Posts: 801
Original Poster
|
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.
|
|
|
05-02-2014, 09:20 AM
|
#18
|
LQ Veteran
Registered: May 2008
Posts: 7,190
|
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.
|
|
|
05-02-2014, 09:50 AM
|
#19
|
Member
Registered: Nov 2010
Posts: 227
Rep:
|
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.
Last edited by eloi; 05-02-2014 at 10:08 AM.
Reason: Text added
|
|
|
05-03-2014, 11:12 AM
|
#20
|
Member
Registered: Jul 2007
Posts: 801
Original Poster
|
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)
|
|
|
05-03-2014, 11:29 AM
|
#21
|
Member
Registered: Jul 2007
Posts: 801
Original Poster
|
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.
|
|
|
05-03-2014, 12:54 PM
|
#22
|
Member
Registered: May 2007
Distribution: Slackware
Posts: 288
Rep: 
|
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').
|
|
|
05-04-2014, 04:46 AM
|
#23
|
Member
Registered: Jul 2007
Posts: 801
Original Poster
|
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 \`"
|
|
|
05-04-2014, 03:47 PM
|
#24
|
Senior Member
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,860
|
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?
|
|
|
05-04-2014, 04:00 PM
|
#25
|
Member
Registered: Jul 2007
Posts: 801
Original Poster
|
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:
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.
|
|
|
05-04-2014, 04:49 PM
|
#26
|
Senior Member
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,860
|
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 or ?
|
|
|
05-05-2014, 10:25 AM
|
#27
|
Member
Registered: Jul 2007
Posts: 801
Original Poster
|
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.
Last edited by Lockywolf; 05-05-2014 at 12:05 PM.
Reason: Bug in the detector script.
|
|
|
05-06-2014, 06:53 AM
|
#28
|
LQ Veteran
Registered: May 2008
Posts: 7,190
|
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.
|
|
1 members found this post helpful.
|
All times are GMT -5. The time now is 12:11 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|