Fixing shell prompts
Slackware's /etc/profile contains the following section relating to shell prompts:
Code:
# Set a default shell prompt: While altering the code to use $0 rather than $SHELL and simply not exporting the PS1/2 would stop the incompatible inheritance issue, it would result in no inheritance at all and a default prompt in non-login shells (which IMO would still be a better choice than the brokenness we currently have but isn't ideal). To make everything nice and tidy I think the prompt stuff needs to be moved out of /etc/profile and into bashrc and equivalents for the other shells, which would make everything work as it should. So, what I'm suggesting: 1) Remove the existing prompt setting code (including the export of PS1/2) from /etc/profile. 2a) Add a /etc/skel/.bash_profile (to run .bashrc for login-shells): Code:
case $- in Code:
[ -f /etc/bashrc ] && source /etc/bashrc 3a) Add a /etc/shinit file along the lines of: Code:
# /etc/shinit Shell environment file 3b) Add the following to /etc/profile in order to make /etc/shinit run: Code:
# Set Shell environment file for traditional bourne shell family: The only one I haven't included in this is zsh as I am unfamiliar with it's inner workings, but I suspect /etc/zshenv might be the correct place to set it's own PS1 in a similar manner. If you only use bash, then the PS string stuff probably won't bother you, but moving the alias definitions to bashrc would have the advantage of making them available in non-login shells so there is still something to be gained. Anyway, those are my thoughts and it's how I have my box configured at present. Over to y'all for comments/suggestions... |
Dear GazL:
I use Slackware with xfce. (and kernel 2.6.10) Don't know why when I enter the terminal from xfce, the prompt doesn't appear and I don't know where I am. If I type export PS1= "\W", everything is OK. How can I do to make it permanent? Regards. Alejandro. |
The safest bet is to add .bashrc and .bash_profile (as I described in 2a and 2b above) to your home directory. That way it should work in a desktop environment independent manner.
|
All my systems are defaulted to KornShell (I just don't really care to use BASH) and terminals on all of them are configured as log in shells in Xfce (KDE is installed -- do like some of the utilities, don't like the overhead); matter of fact all shells are configured as log in shells no matter what window manger I use.
I do the prompt with a file, /etc/profile.d/ksh.sh (which is simply an edited part of /etc/profile): Code:
#!/bin/sh Code:
fubar-trona-/home/trona: I also have, in each user home directory, .profile, .kshrc and .exrc. The .profile sets "useful" environment variables specific to the individual user: Code:
fubar-trona-/home/trona: cat .profile I also set, for me only, the current working directory as first on ${PATH} followed by my ${HOME}/bin; I'm well aware of the hazards of so doing and have been doing it for about 30 years and don't need any argument about it: It's my party and I'll cry if I want to. ~/.kshrc simply sets some aliases I like: Code:
fubar-trona-/home/trona: cat .kshrc Code:
fubar-trona-/home/trona: cat .exrc Defining terminal windows as log in shell does no harm -- you execute su -, you get root's environment. When you exit, you're back to your own environment (su - forks and executes in a new shell and when it exits that environment is gone). Simply demonstrated with Code:
fubar-trona-/home/trona: su - So, basically, I don't really see the problem with /etc/profile -- especially if you add custom files in /etc/profile.d, which, for example, would include things like Apache Ant, Apache Maven, Apache Tomcat, Java (jdk.sh and jdk.csh) and one that I add for the Generic Mapping Tools, gmt.sh, which sets environment variables for it -- that's what /etc/proifle.d is for, no need to mess with the default /etc/proifle (as in the Goode Olde Days when that was your only choice for system-wide settings). Good thinking, but I'm not sure there's actually a problem. |
Quote:
To be fair, this is probably a corner-case, as most people won't be using the -l option to start a login shell, and are especially unlikely to do so for a shells other than their default. I think the exporting of PS1/2 is what I object to most (but I guess that actually suits people who only ever use bash, though it does cause problems for the other shells). I think that ideally I'd like to see /etc/profile not contain anything other than tradition 'sh' compliant stuff - even if this would mean having to stick with the less feature-full default '#' prompt out of the box. Thanks for posting your setup. I found it interesting. :) P.S. I'd forgotten about 'su', so using $0 rather than $SHELL isn't going to work in all situations either. I think the last time I looked at this stuff I ended up doing a test -n "$BASH_VERSION" to reliably identify a bash shell, but not all shells have a unique environment variable like that to select on. Given this added complexity, I think I'm leaning even more to not setting the prompt at all in /etc/profile and letting it default. |
Huh.
Yup, see what you mean, but also see that it's highly unlikely that somebody would be switching back and forth (you learn one, the others are just unnecessary confusion -- think C-Shell here, what a mess that is). Absolutely, positively have to run a shell program in some other shell? That's what pound-bang is for, eh?. There was (and still is) nothing wrong with Bourne, David Korn made it better (a lot better, IMHO). Berkeley went off in the blue somewhere or 'toher (what were those guys smoking when they came up with C-Shell?). BASH, well, Bourne + Korn + ... well, I dunno (and they seem to be unable to leave the damned thing alone!). Anyway, getting off that tangent, some good thinking. |
I know what you mean about csh. Never got on with that.
Anyway, for the sake of completeness, here's a revised /etc/shinit that takes care of the '-su' issue it was missing before: Code:
# /etc/shinit Shell environment file BTW, While we're on the subject: Any reason /bin/sh is not in /etc/shells? |
Thanks to all!
I'll come back when I finish an try all this. Regards. Alejandro |
+1 for not exporting $PS1 and $PS2.
+1 for providing a default .bash_profile and .bashrc, and for setting up .bash_profile to source .bashrc. I assume that all of these shells set up their own default prompt if we leave $PS1 alone. Is there any reason why we override it globally? To me it seems like it should be set on a per-user basis, so in .bashrc or equivalent for their shell of choice. |
The shells will default to their own prompt strings: most of which are not particularly helpful (e.g. bash uses "bash-4.2$"), but as I said in the first posting I'd rather have that than have the currently broken behavior we see from exporting PS1/2.
My guess is that they are overridden just to set a more useful system-wide default prompt, and exported so that they inherit down to child shells. Unfortunately this solution, though simple is a bit hit-n-miss and as shown above has side effects. |
All times are GMT -5. The time now is 11:27 PM. |