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 |
Quote:
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: 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:
|
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 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. |
Quote:
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:
Quote:
Quote:
|
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:
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: PS1 is an env variable (not shell). Why isn't it inherited by the closest child process? (startx) |
Asked myself, answered myself:
http://superuser.com/questions/66306...d-variable-ps1 Quote:
The solution to the second problem awaits to be found. |
Quote:
|
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 \`" |
Quote:
|
Quote:
Code:
source $ENV Code:
source `if [ shopt -o login_shell ]; then x="/etc/profile"; else x="/etc/sh.shrc"; fi \` Further expanding to: Code:
source /etc/profile Code:
source /etc/sh.shrc As long as the shell is /bin/sh (posix-mode), it would perform different (appropriate) inits depending on it being login or non-login. |
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 } Code:
source `burp` Code:
source $( burp ) |
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 Code:
#!/bin/sh (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 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. |
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. |
All times are GMT -5. The time now is 01:05 AM. |