LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-02-2014, 07:42 AM   #16
eloi
Member
 
Registered: Nov 2010
Posts: 196

Rep: Reputation: 50

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
 
Old 05-02-2014, 08:55 AM   #17
Lockywolf
Member
 
Registered: Jul 2007
Posts: 70

Original Poster
Rep: Reputation: 15
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.
 
Old 05-02-2014, 09:20 AM   #18
GazL
Senior Member
 
Registered: May 2008
Posts: 3,364

Rep: Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899
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.
 
Old 05-02-2014, 09:50 AM   #19
eloi
Member
 
Registered: Nov 2010
Posts: 196

Rep: Reputation: 50
Quote:
Originally Posted by Lockywolf View Post
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
 
Old 05-03-2014, 11:12 AM   #20
Lockywolf
Member
 
Registered: Jul 2007
Posts: 70

Original Poster
Rep: Reputation: 15
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)
 
Old 05-03-2014, 11:29 AM   #21
Lockywolf
Member
 
Registered: Jul 2007
Posts: 70

Original Poster
Rep: Reputation: 15
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.
 
Old 05-03-2014, 12:54 PM   #22
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 227

Rep: Reputation: 91
Quote:
Originally Posted by Lockywolf View Post
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').
 
Old 05-04-2014, 04:46 AM   #23
Lockywolf
Member
 
Registered: Jul 2007
Posts: 70

Original Poster
Rep: Reputation: 15
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 \`"
 
Old 05-04-2014, 03:47 PM   #24
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,473

Rep: Reputation: 412Reputation: 412Reputation: 412Reputation: 412Reputation: 412
Quote:
Originally Posted by Lockywolf View Post
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?
 
Old 05-04-2014, 04:00 PM   #25
Lockywolf
Member
 
Registered: Jul 2007
Posts: 70

Original Poster
Rep: Reputation: 15
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.
 
Old 05-04-2014, 04:49 PM   #26
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,473

Rep: Reputation: 412Reputation: 412Reputation: 412Reputation: 412Reputation: 412
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 )
?
 
Old 05-05-2014, 10:25 AM   #27
Lockywolf
Member
 
Registered: Jul 2007
Posts: 70

Original Poster
Rep: Reputation: 15
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.
 
Old 05-06-2014, 06:53 AM   #28
GazL
Senior Member
 
Registered: May 2008
Posts: 3,364

Rep: Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899
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.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Dotfiles becoming undotted in 64-13.1 ahmadj Slackware 9 12-24-2010 01:50 PM
Auto-sourcing indienick Slackware 2 08-06-2008 08:58 AM
Archive dotfiles and dotdirectories only mjmwired Linux - Software 3 05-28-2008 10:01 PM
Sourcing .bashrc shifty_eyes Linux - Newbie 3 09-25-2005 09:43 PM
Command line: How do I filter for dotfiles only? unamiccia Linux - General 21 04-14-2004 06:10 PM


All times are GMT -5. The time now is 05:14 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration