There are 3 problems with the way /etc/profile sets up the PS1 shell variable: 1. There are numerous bugzilla reports that konsole has lost its PS1 definition in recent baselayouts. For example, #26603, #23297, #25596 The stock answer has been that konsole should be launched as a login shell, as "konsole -ls" but I dont buy that..... I have things in .bash_profile that are too expensive to run for every terminal. My .bash_profile would have already been run once anyway, by kdm, at login. This is as it should be. Surely we cant be recommending "xterm -ls" too. IMO the obvious solution is that /etc/profile is the wrong place to be setting a colored PS1. Everything would be right if the current code was run in ~/.bashrc, at the same time as setting up dircolors and xterm window titles. (ive not been able to find a rationale for that stock answer, so my apologies if my 'obvious solution' has already been considered and rejected) 2. In a related problem, the current check if [ "$TERM" != 'dumb' ] && [ -n "$BASH" ] doesnt cope well with all the non-color terminals that are not 'dumb'. GNU dircolors already contains a database of TERMs that support color - we should reuse that by changing the test to: if dircolors --print-database|grep -q \^TERM.$TERM\$ && [ -n "$BASH" ] 3. If the terminal doesnt support color it should set a sensible non-color PS1, rather than leaving bash's terrible default.
and i'm not buying your reasoning ;)
Yeah, try harder! Following this argument from the beginning, it seems like everytime this very subject is brought up again, it's either ignored or marked 'WONT' or 'INVA'. I think I read somewhere (mailing list or policy guide, can't remember) some dev saying to always check what the other distros are doing, and not to do things differently just for the sake of doing things differently. So I was wondering, what is the exact advantage of starting every subshell as login shell, and what is so bad about the way other distributions do it? To add more examples why the current way is suboptimal: 1. I'm using a program that can start xterms (actually any terminal emulator, it's configurable) in a modified environment (directories added to PATH); if xterm starts a login shell, it resets PATH to the system default, if it doesn't, PS1 is reset to bash's default. Works perfectly on any other distro / commercial UN*X. 2. On the machines I work with, a user with tcsh as login shell can type "bash" at any prompt and gets the exact same environment and look&feel as a bash user gets. A user with bash as login shell can type "tcsh" at any prompt and gets the exact same environment and look&feel as a tcsh user would get. This will only work if environment setting (PATH, MANPATH, DIR_COLORS, &c.) are done in /etc/csh.login and /etc/profile; and other stuff specific to a particular shell (prompt, aliases, completion, &c.) in /etc/csh.cshrc, ~/.bashrc, and whateter $ENV points to for POSIX compliant sh shells. (the default .bashrc here only contains "[ -r /etc/bash.bashrc ] && . /etc/bash.bashrc", so if there are updates to the system wide one they're still picked up by users without the need to mess with their private files). This even works in an environment where home dirs are shared between different architectures. Yes I know there are ways to work around (1) and according to bug #13579, tcsh support isn't what it should be. Yes, I know I can set PS1 in my ~/.bashrc. Still I think making this the the default and just moving PS1 to the correct file in the first place would have been a lot less work than to add -ls to everywhere an xterm etc. is started; or even to patch terminal emulators to start login shells by default (as done to gnome-terminal!). And even if the current way should be the correct way, could one of the maintainers please explain here what makes it superior to avoid future bug reports? Thanks in advance and sorry for my poor english.
the biggest problem i have with moving PS1 to ~/.bashrc and from /etc/profile is maintaince ... imo PS1 is a system wide default that local users can override if they want ... if you move it out of PS1 and into .bashrc it requires users to have .bashrc setup, and it means that you cant override it in /etc/profile another problem is that you would then lose PS1 in login shells ... login shells read .bash_profile and /etc/profile, not ~/.bashrc ... surely you wouldnt suggest we put 'source ~/.bashrc' in /etc/profile ;)
> biggest problem.....is maintaince As mentioned in comment 3, the solution in other distros is for ~/.bashrc to contain only: [ -f /etc/bashrc ] && ./etc/bashrc > surely you wouldnt suggest we put 'source ~/.bashrc' in /etc/profile Gentoo, along with every other distribution, already has exactly that in ~/.bash_profile > another problem is that you would then lose PS1 in login shells Half-baked idea: what if /etc/profile set up a basic PS1 (to wipe out any trace of the terrible bash default), and /etc/bashrc (or whatever) sets up colors. The worst that can happen with a misconfigured home directory is that you lose colors.
i missed that ... i saw tcsh and just ignored the rest of it ;) i like the idea of /etc/bashrc ... if we move PS1 from /etc/profile to /etc/bashrc i'd support that ... then .bash_profile would source .bashrc (as you pointed out ... ive always created my own .bash_profile and .bashrc from scratch so i missed out it was the default) and .bashrc would source /etc/bashrc thus everything would be great
Created attachment 16391 [details] /etc/profile that sets PS1 with no colors for all terminal types
Created attachment 16392 [details] /etc/skel/.bashrc that sources /etc/bashrc
Created attachment 16393 [details] /etc/bashrc that contains the old content of /etc/skel/bashrc, plus colored PS1
That /etc/profile contains a "umask 002" from my personal setup that isnt wanted in standard gentoo, but otherwise this looks good to me.
Not so fast...there's another way to get the same functionality without relying on the user sourcing the global `/etc/bashrc'. Bash-2.05a and earlier used to have reading a system-wide `/etc/bash.bashrc' built in, and I'd be surprised if it's missing in 2.05b (can't check this until the weekend though)... To use it, look at the bottom of one of the files included by `configure.h' in bash's top-level source directory, there should be two defines mentioning `/etc/bash.bashrc' and `/etc/bash.bash_logout'. Uncomment those, et voila, bash will use'em. Only distro I know that does this though is Debian (potatoe and woody), so maybe a bit non-standard...
Yes! That's it! Found it in bash-2.05b/config-top.h, right near the bottom: /* System-wide .bashrc file for interactive shells. */ /* #define SYS_BASHRC "/etc/bash.bashrc" */ /* System-wide .bash_logout for login shells. */ /* #define SYS_BASH_LOGOUT "/etc/bash.bash_logout" */ And it works! Now if /etc/profile sources /etc/bash.bashrc, user's files could be installed empty, and there is no way for them to end up with no prompt! Spanky, does that sound ok to you?
*** Bug 23297 has been marked as a duplicate of this bug. ***
*** Bug 27128 has been marked as a duplicate of this bug. ***
sounds wonderful ... azarah, you see what we want or shall i put together a summary for you ?
Do not really know if I want the summary or not :P Problem is that this is fairly dependant on preferences, and as we are supposed to cater for the 'professional', I always figured that most people are like me that customize his own damn .bash* - seems not the case. Anyhow, biggest reason why there is still so many open bugs about this, or just closed ones, is that people by default grabs the arm when offered the little finger ... I am pretty sure that in a month or two I am going to be drowned in new request for this new 'neat feature' that the user just cannot live without!! I will be adding stuff that on first time login for user ask if he wants his PS1 displayed between roses, hearts, clubs or teddy bears :/
i dont see how this is dependend on preferences ... we move PS1 and such to /etc/bashrc, a global bashrc ... that way all users have PS1 regardless of whether they ran a login shell or not ... and although the 'fix' before was to tell them to run a login shell, there are sometimes where login shells really are not appropriate ... this 'fix' would take care of all the open bugs about PS1/environment not being set correctly ...
Yes, but the /etc/bash.bashrc is the first sane suggestion for this specific issue. Others included sourcing /etc/profile by default in ~/.bashrc. And above rant is more for 'profile changes' in general.
which is why i offered a summary :P the bug report brought all ideas/conflicts together ... basically just review starting with comment #10 ... everything from that point on is what we really want ...
You can if you want, but I get the idea. Anyhow, 'sane idea' refer to many other bugs closed, or left for forgotten ;/
Actually, make a patch - best summary ever :P
From comment 11: > Now if /etc/profile sources /etc/bash.bashrc But that would mean that user with a login shell other than bash would have /etc/bash.bashrc sourced at login. Any opinions on patching bash so that it sources /etc/bash.bashrc after /etc/profile for login shells too? (I dont understand *why* bash works the way it does... why isnt this the default?)
One could source bash.bashrc only if profile is read from bash. But still, now that almost one month is gone; any progress on this?
My preference is still to not patch bash, and use the structure illustrated by the attachments. To summarize: /etc/profile contains nothing bash-specific. It sets up a basic PS1 without colors. ~/.bash_profile is unchanged from today, and it sources ~/.bashrc ~/.bashrc contains very little, except to source /etc/bashrc. /etc/bashrc sets up the standard bash-specific environment variables and shell customisations, including setting a colorful PS1. This resolves all the kdm/konsole issues raised in previous bug reports. It also achieves a sensible abstraction between the core profile in /etc/profile, and the bash-specific shell customisations in /etc/bashrc (which the user can customise, or opt out of, using ~/.bashrc) It also provides and adequate upgrade path from the current structure. Any user account which has never changed their ~/.bash* will lose their colored bash prompt until they update their ~/.bashrc based on /etc/skel/.bashrc.
another month see what I said in comment #2?
bash-2.05b-r8 (still in ~arch) includes a patch to bash to get it to read .bashrc if it started direct from ssh. See bug #24762 That patch will interfere with all the solutions proposed here; .bashrc would get run twice when started from sshd. (perhaps I should submit a patch to get bash to detect whether it has been run from konsole or an xterm too ;-) Are there any gentoo devs watching this issue? Its not clear to me whether this issue is being ignored, or whether someone is waiting for something? If so, can we help?
I dunno One comment already says that Debian is doing it. My own research revealed that SuSE is doing it; SuSE in particular has SYS_BASHRC, SYS_BASH_LOGOUT, NON_INTERACTIVE_LOGIN_SHELLS, and SSH_SOURCE_BASHRC all defined; and they already did it at times when they actually still cared about command line users in their desktop versions. Our shell guy has set up gentoo this way, and I never once have seen .bashrc being run twice, not from ssh or anywhere else. Other distributions source a global file from ~/.bashrc, or define PS1 in ~/.bashrc. But no-one else starts terminals as login shells. Devs, whatever you decide the best way is, the longer you wait the more difficult it will be to upgrade! If you look at gentoo-user ML and forums.gentoo.org, a lot of users think the right way is to source /etc/profile from ~/.bashrc or something more adventurous! Because files in $HOME are off-limit for ebuilds to modify, the more users try to fix the situation themselves, the more bug reports there will be should there be a correctly configured bash one day!
*MONTHLY REMAINDER*
*** Bug 35122 has been marked as a duplicate of this bug. ***
A finally a bug report about this issue that seems to know what the hell is going on. Now just to actually get it released again. I've just realised that there was actually an "export PS1=..." statement orriginally in the /etc/skel/.bashrc file, this seems to have disappeared at some point. I personally like the idea of having the default ~/.bashrc file source /etc/bashrc, this way those users who do not want /etc/bashrc sourced can remove it. Also, having .bash_profile source .bashrc is already default, this way everybody is happy (almost). So basically the "includes" will work something like: login shells: * /etc/profile * ~/.bash_profile -> ~/.bashrc -> /etc/bashrc non-login shells: * ~/.bashrc -> /etc/bashrc This way the user also has more control about when /etc/bashrc gets sourced. Could we get this implemented asap please? I've got over 200 machines to go update so it would be appreciated if we can get this into the stable release asap! Thanks.
*** Bug 35219 has been marked as a duplicate of this bug. ***
I am assuming nobody saw that the PS1 stuff is in /etc/skel/.bashrc for months already (unstable, and possibly stable baselayout now - have not checked). I do not agree with having it in a system-wide config file, as once again you cannot then just delete it if you do not like it. Then for the dircolor stuff - please make neat changes, and do a diff -u agaist latest unstable baselayout's files (currenlty 1.8.6.12-r2), and attach. Same for colour PS1 ...
it's easier to override PS1 (unset PS1) than it is to try to make sure all instances of bash use it the fact that it's in /etc/skel/.bashrc means nothing for people who dont use standard utils for creating accounts ... some people just edit /etc/{passwd,shadow} and then make the home directory ... having to copy over /etc/skel/.bashrc isnt always obvious
Well, those users are usually truly hardcore users (or stubborn users), and most of them should know how to fix these problems by hand for themselves. If they know how to edit /etc/passwd and /etc/shadow and /etc/group files, certainly they can figure out how to do "cp -R /etc/skel /home/whatever"? Before this looks like slamming, I like editing these files by hand as well in many cases.
newest baselayout still sets PS1 in /etc/profile; which is still broken (1) shells who dont understand bash extended PS1 syntax and read /etc/profile receive a messed up prompt (2) users with a csh type login shell still get a very ugly default PS1 in interactive bash sessions (3) same still true for X terminal emulators (4) env vars irrelevant in non-interactive shells still dont belong in /etc/profile
Hmpf, this still has not been fixed/resolved. Could we stop flaming one another and please find a solution to this? It was really anoying to had to fix over a hundred user's ~/.bashrc last time (without breaking those who made customizations) and the next batch of new students is on their way. Yes, I could probably make my own customizations to /etc/skel/.bashrc, but then there might be decided on an alternate solution... Any good reasons why we can't put the PS1 back into /etc/skel/.bashrc?
The proper way to fix this, IMO, would be to have some equivalent /etc/bashrc that is sourced before the user's .bashrc IIRC, the only way to do this would be to patch BASH or to add ". /etc/bashrc" to the start of the skel's .bashrc file.
As in comment 29?
Looks like it, yes. I was only responding to comment 35 which was in my email.
Okey dokey, I'm looking at this now and will get it fixed. There's a lot of suggestions here but not quite enough knowledge of why bash does what it does. For example, when PS1 is unset that indicates that bash believes the shell is non-interactive: http://www.gnu.org/software/bash/manual/bashref.html#SEC75 I'll emerge the KDE stuff to be able to try konsole and test the behavior. I'm not opposed to SYS_BASHRC, SYS_BASH_LOGOUT, NON_INTERACTIVE_LOGIN_SHELLS, and SSH_SOURCE_BASHRC, etc. but I want to understand the reason for each one's existence before setting it. Here are some questions I have: 1. Why does bash *only* read /etc/profile and .bash_profile on a login shell? Why not also read .bashrc? Is this broken historical behavior or is there a reason for it? 2. Why is it necessary to set SYS_BASHRC to get that behavior? Why is this not the bash default? Is it historical and therefore would make sense to use the non-default setting (same as setting nocompatible in vim for example) 3. What files do we want to be read in each situation, and what modifications need to be made to make it happen? cron job non-interactive ssh session interactive ssh session default xterm settings xterm -ls login at console as xdm starts an x-windows session as kdm starts a kde session as gdm starts a gnome session Btw, my gut feeling is that we should be setting SYS_BASHRC and SYS_BASH_LOGOUT by default at least. Here is why: 1. Without SYS_BASHRC, the system administrator has no way to do additional settings for each invocation of bash, other than to put things in the user's .bashrc (for example then sourcing /etc/bashrc). This doesn't make any sense because it means that the system administrator is out of control... the user can prevent the system bashrc from running. In other words, the user is setting the policy instead of the system administrator. 2. With SYS_BASHRC, the system administrator sets the policy. It's possible for the system bashrc to be blank, in which case the policy gives all the control to the users. But the system administrator has the *ability* to set a different policy, which makes all the sense in the world. Once we get the questions answered, I'll get the right patches into the bash ebuild, skel files, /etc/profile, etc.
.bashrc is meant for setting environment variables. Whether or not the system bashrc can be overridden, the user's .bashrc could still unset or change such variables just as easilly. Putting non-variables in bashrc can theoreticly screw up scripts, I think. All interactive stuff should be in the profile. The reason PS1 is unset is because the startx script (and many others, I'm sure) are BASH scripts. When BASH runs those scripts, it unsets PS1 and this is passed down to all applications launched by such scripts such as KDE's Kicker and KDesktop. When a user runs Konsole, whether from the menu/quicklaunch (Kicker) or the Run dialog (KDesktop), the PS1 variable is still unset. Ideally, it might be better for BASH to use a backup of the PS1 (etc) variables and restore them when calling another script/program, but I suspect that would probably slow scripts down a lot when they are only doing simple things like piping to grep or such.
> .bashrc is meant for setting environment variables > Putting non-variables in bashrc can theoreticly screw up scripts, I think. > All interactive stuff should be in the profile. This needs some clarification. Historically it works like this: bash_profile is read for login shells, and it is intended for environment settings that will persist into subshells. bashrc is read for non-login shells, both interactive and non-interactive. A non-interactive shell can be distinguished from an interactive shell by testing $- or by checking for null $PS1. Following the check for an interactive shell, bashrc is a perfectly acceptable place to put commands that you want run for every interactive shell. For example, my own bashrc sets some basic variables at the top of the script. Then it does a PS1 check for interactivity. Following that, it sets up shell functions and aliases, runs keychain, does some X interaction to determine the xterm background color, etc. See http://www.gnu.org/software/bash/manual/bashref.html#SEC65 > Whether or not the system bashrc can be overridden, the user's .bashrc > could still unset or change such variables just as easily. Leaving the policy to the system administrator still makes sense, provided the system administrator doesn't screw things up. > The reason PS1 is unset is because the startx script (and many others, I'm > sure) are BASH scripts. When BASH runs those scripts, it unsets PS1 and this > is passed down to all applications launched by such scripts such as KDE's > Kicker and KDesktop. When a user runs Konsole, whether from the > menu/quicklaunch (Kicker) or the Run dialog (KDesktop), the PS1 variable is > still unset. Ok, this needs to be clarified also. It is possible for this to happen if PS1 is set to "", but it is not possible if PS1 is unset. For example, try the following commands. Note that +ls means not-login-shell export PS1= xterm +ls -e bash --norc # note blank prompt unset PS1 xterm +ls -e bash --norc # note *default* prompt So in other words it's impossible for the unset PS1 to trickle down to terminals due to bash scripts like startx. You can even prove that like this: export PS1= bash -c 'xterm +ls -e bash --norc' This effectively is running the xterm inside of a "script" environment. So you export a blank PS1, then bash runs the script environment which unsets PS1, then it runs the xterm which runs bash, which uses the default PS1 setting. > Ideally, it might be better for BASH to use a backup of the PS1 (etc) > variables and restore them when calling another script/program, but I suspect > that would probably slow scripts down a lot when they are only doing simple > things like piping to grep or such. That's totally unnecessary. Now that I've read more of the bash documentation, I can answer some of my own questions: > 1. Why does bash *only* read /etc/profile and .bash_profile on a login shell? > Why not also read .bashrc? Is this broken historical behavior or is there a > reason for it? The bash documentation specifically says: So, typically, your `~/.bash_profile' contains the line if [ -f ~/.bashrc ]; then . ~/.bashrc; fi > 2. Why is it necessary to set SYS_BASHRC to get that behavior? Why is this > not the bash default? Is it historical and therefore would make sense to use > the non-default setting (same as setting nocompatible in vim for example) Reading the bash info pages and the bash source, my best guess is that this is purely historical and that enabling SYS_BASHRC makes sense. > 3. What files do we want to be read in each situation, and what modifications > need to be made to make it happen? > > cron job non-interactive, non-login, so bashrc will be read. PS1 is unset > non-interactive ssh session non-login non-interactive, bashrc is read as long as SSH_SOURCE_BASHRC is set, otherwise nothing is read. It seems clear that we want to set SSH_SOURCE_BASHRC, otherwise there is no opportunity to set environment variables when ssh is run non-interactively. PS1 is unset > interactive ssh session This is a login shell, which makes sense since it doesn't descend from an earlier login shell for the same user. As a login shell, bash_profile is read which then should read bashrc to pick up those settings as well. PS1 is set to its default setting by bash. > default xterm settings Non-login shell, interactive, reads bashrc. PS1 is set to default. > xterm -ls > login at console (both) Login shell, interactive, reads bash_profile (which should then read bashrc). PS1 is set to default. > as xdm starts an x-windows session /etc/X11/xdm/Xsession has #!/bin/bash --login so it would source bash_profile. Since the shell is non-interactive, PS1 would be unset > as kdm starts a kde session I don't have this one installed at the moment, but it's probably like xdm/gdm > as gdm starts a gnome session Via /etc/X11/gdm/Xsession, bash_profile is read. Since the shell is non-interactive, PS1 would be unset. -------------------------------------------------------- So here is what I'm planning at this point: - Figure out why konsole is loses its PS1 definition. Right now I'm seeing this as a possible konsole problem because it works fine in stock xterm. - Build bash with the various SYS_* discussed - Clean /etc/profile, moving things to /etc/bash.bashrc following the test for interactivity [[ $- == *i* ]] - /etc/profile will source /etc/bash.bashrc for the sake of login shells
> > as gdm starts a gnome session > Via /etc/X11/gdm/Xsession, bash_profile is read. > > > as kdm starts a kde session > I don't have this one installed at the moment, but it's > probably like xdm/gdm I dont have gnome installed to check, but I think there may be a difference here..... kdm will run .profile, but not ~/.bash_profile. That contradicts what I wrote in comment 1 in August 2003; Im not sure if I was mistaken or if kde has changed. Another twist is that the startkde script starts #!/bin/sh --login, so .profile is run *twice* (if you have got one) but .bash_profile not at all.
Thanks Toby. I'm not sure if xdm is doing it right because I don't think we (yet) enable NON_INTERACTIVE_LOGIN_SHELLS for bash. The only one of gdm/kdm/xdm that I'm sure about is gdm because it explicitly sources .bash_profile
If you stop xterm from being starting a *login* bash session then youd realise that it too breaks. The only reason PS1 broke for gentoo is becaus the deffinition moved from /etc/skel/.bashrc to /etc/profile. In /etc/profile there is a check for whether we are running a color terminal or a dumb terminal and also whether we are actually using bash and and and..., and sets the PS1 variable according to that (sorry, can't recover the test - I nuked it about 5 seconds after I found it). It is this that breaks konsole, aterm, xterm (unless you use -ls to start it up - which is to what the gentoo default was changed - try running "who" after opening up a few xterms): jaco@pug jaco $ who jaco :0 Jun 30 18:46 jaco@pug jaco $ xterm & [1] 7748 jaco@pug jaco $ who jaco :0 Jun 30 18:46 jaco pts/390 Jun 30 19:40 (:0.0) jaco@pug jaco $ Which is simply put *wrong*. But once the PS1 problem has been fixed, we can fix that too. aterm and konsole does the correct thing - PS1 needs to be either inherited from the kdm login process (wrong) or set using ~/.bashrc or /etc/bashrc. We don't *need* any of those extra defines for bash but a SYS_BASHRC would be nice. I'm not sure on what happens with the ~/.bashrc with ssh but I do get the following after adding "echo blah" to it: jaco@pug jaco $ scp jaco@localhost:.xinitrc temp Password: blah jaco@pug jaco $ which doesn't start an interactive shell afaik? Thus .bashrc actually does gets sourced (even though the scp actually failed :). So my question here is what does SSH_SOURCE_BASHRC actually do differently than normal? Note that the PS1 being set is not a reliable test for interactive shells becaus it can be exported (and thus being set) at any point in time, even in non-interactive shells.
Jaco, the whole login shell thing I explained in comment #41 and demonstrated that it doesn't matter for bash to get a default PS1 setting. The point is whether PS1 is unset or exported NULL in the environment, and whether bash thinks it is interactive or not. I am well aware of the differences between login shells and non-login shells, so please don't explain them any more. I'm also aware of the fact that it would be better to move PS1 setting to /etc/bash.bashrc following the test for interactivity, again, as I essentially said in the closing of comment #41 Regarding SSH_SOURCE_BASHRC, you're right, it looks like we shouldn't need that. I repeated your test here (using pure ssh instead of scp) and it worked the way you described. Regarding PS1 not being a reliable test for an interactive shell, you're both right and wrong. It's not a reliable test for an interactive shell because it can inherit a NULL setting. HOWEVER it is a reliable test for a non-interactive shell because it is always unset in that situation. For example, try this: env PS1="testing" bash -c 'echo $PS1' In any case, it's better to test $- for *i* since there won't be any ambiguity.
> env PS1="testing" bash -c 'echo $PS1' Point taken - wasn't aware of this one. I'm not sure whether PS1 is inherited when doing a "/bin/bash" or whether it gets set a new (probably the latter...). Also, the example /etc/bashrc that is attached doesn't take into consideration non-color terminals (I'm not aware of any, but afaik these should simply ignore those escape codes so it should be fine). And from Comment 41: So here is what I'm planning at this point: - Figure out why konsole is loses its PS1 definition. Right now I'm seeing this as a possible konsole problem because it works fine in stock xterm. It never gets set as we've got it now (being set in /etc/profile the only login shell is that which is executed by startx) at which point $TERM == dumb which will fail the test [ "$TERM" != 'dumb' ] :). konsole then starts as a non-login shell so /etc/profile doesn't get sourced. As explained in my previous comment the "stock" xterm works becaus the gentoo maintainer has made it into a login shell using -ls as a default option. This is a *bug*. It should *not* be working. - Build bash with the various SYS_* discussed hmm, good idea - the only one then remaining iirc is the one that causes /etc/bashrc (or some variation on that name) to be sourced as a system bashrc. - Clean /etc/profile, moving things to /etc/bash.bashrc following the test for interactivity [[ $- == *i* ]] Well, as long as you handle it such that you don't require any interactivity with the user there is no need for a test for interactivity. We know it's bash which can handle the PS1 we're about to set in there and if it is a non-interactive shell it'll simply be ignored. This prevents the spawning of a "test" process, at the cost of always setting PS1 - whether it is required or not. - /etc/profile will source /etc/bash.bashrc for the sake of login shells Why? All stuff in /etc/bash.bashrc will be (or should be) bash specific. And bashrc (and /etc/bash.bashrc) will *always* be sourced for both interactive and non-interactive shells. Oh, but you say *login* shells. Maybe just do something like: [ `basename $SHELL` == "bash" -a -r /etc/bash.bashrc ] && . /etc/bash.bashrc in order to ensure that we are only including /etc/bash.bashrc if it actually exists *and* is readable (enforcing rules for non-interactivity), and only if /etc/profile is actually being sourced by bash. This way /etc/bash.bashrc can be guaranteed to only ever be seen by bash, as such, /etc/bash.bashrc can assume being sourced by bash. Appologies for yet another essay :).
> Also, the example /etc/bashrc that is attached doesn't take into > consideration non-color terminals (I'm not aware of any, but afaik > these should simply ignore those escape codes so it should be fine). To be honest, I haven't even glanced at the attached files yet. I've been more interested in the problem and best solution than proposed changes to the files. ;-) > > Figure out why konsole is loses its PS1 definition. Right now I'm > > seeing this as a possible konsole problem because it works fine in > > stock xterm. > > It never gets set as we've got it now (being set in /etc/profile the > only login shell is that which is executed by startx) at which point > $TERM == dumb which will fail the test [ "$TERM" != 'dumb' ] :). > konsole then starts as a non-login shell so /etc/profile doesn't get > sourced. Ok, well at least this should be fixed by moving PS1 definition to bashrc. Thanks for the explanation. > As explained in my previous comment the "stock" xterm works becaus the > gentoo maintainer has made it into a login shell using -ls as a > default option. This is a *bug*. It should *not* be working. Really?!? I don't see any xterm patches or configuration options that are changing this. I also tested with +ls on the command-line and it works fine. I'm not arguing necessarily that "xterm works and konsole doesn't" but I don't think that your explanation is quite right since I've definitely tested xterm as both -ls and +ls Anyway, once again, any problems here should disappear with bashrc containing PS1 and environment setup. > > Clean /etc/profile, moving things to /etc/bash.bashrc following the > > test for interactivity [[ $- == *i* ]] > > Well, as long as you handle it such that you don't require any > interactivity with the user there is no need for a test for > interactivity. We know it's bash which can handle the PS1 we're about > to set in there and if it is a non-interactive shell it'll simply be > ignored. This prevents the spawning of a "test" process, at the cost > of always setting PS1 - whether it is required or not. Yes, we want to test for interactivity because there are personal bashrcs out there that use the older, PS1-based test for interactivity. We don't want to to break those, so we need to retain the behavior described in the man-page. Regarding your last point, I understand that /etc/profile will need to test for bash prior to sourcing /etc/bash.bashrc for login shells. That's kinda "duh" ;-) But I would test using BASH_VERSION instead of using a subprocess and running basename... I think we're on the same page. At least the same web page. :-)
Changes are in bash-2.05b-r10 and committed to rc-scripts cvs. I'll roll a new baselayout soon to get those changes out.
baselayout-1.10.2 released
Three nitpicks: 1. All distributions that set SYS_BASHRC set it to /etc/bash.bashrc because startup file handling resembles that of (t)csh (csh/tcsh look for a file named /etc/csh.cshrc). Is it really necessary gentoo does something completely non-standard here AGAIN? 2. The else clause sets PS1='\u@\h \w \$ ', a bashism non-bash shells don't understand; which means users with ash/dash/ksh as their interactive shell will see a funny prompt. 3. Interactive POSIX-compliant bourne shells do not read /etc/profile either; which means users with ash/dash/ksh as their interactive shell will see the shell's default prompt in x-terminal emulators.
Not sure about #1... I haven't upgraded so I'm not sure what the details are of it yet. Personally, I'd prefer /etc/bashrc or similar. As for #2 and #3, non-BASH shells shouldn't be messing with a bashrc file, so they're not relevant...
All Linuxes known to mankind that define SYS_BASHRC use /etc/bash.bashrc (semi-standard). gentoo now uses /etc/bash/bashrc . The quoted PS1 is defined in /etc/profile, hence it's relevant to all bourne shells.
Wasn't the entire purpose of this bug to put PS1 in bashrc?
Hi Hans, Let's back up to comment #50. > 1. All distributions that set SYS_BASHRC set it to /etc/bash.bashrc because > startup file handling resembles that of (t)csh (csh/tcsh look for a > file named /etc/csh.cshrc). Is it really necessary gentoo does something > completely non-standard here AGAIN? Actually, it's standard within the context of Gentoo. Although there are exceptions, we're trying pretty hard to keep application-specific files in their own directories inside /etc. I don't see keeping the location of the system bashrc consistent between distributions as important. Besides, most people will type "vim /etc/bash<tab>" at which point they'll find it anyway. ;-) I understand your objection and I'm not trying to ignore it, but I think either argument for the placement of bashrc is good. I chose to do it this way. > 2. The else clause sets > > PS1='\u@\h \w \$ ', > > a bashism non-bash shells don't understand; which means users with > ash/dash/ksh as their interactive shell will see a funny prompt. That's true. It's something we should fix. The current situation is at least better than the previous situation. The "funny prompt" was much worse then! Regarding ksh, are you certain? I thought it understood a similar set of sequences as bash. > 3. Interactive POSIX-compliant bourne shells do not read /etc/profile > either; which means users with ash/dash/ksh as their interactive shell > will see the shell's default prompt in x-terminal emulators. Well, they don't have a lot of options, do they? Do you have suggestions on this front? Thanks for your comments.
Just installed the new baselayout and needed bash-3.0-r4 Don't you want \W (as opposed to lowercase \w) in the /etc/bash/bashrc like the original prompt from /etc/profile had? Case sensitive, remember... Also, the seperate root PS1s were lost in this transition.
Created attachment 36799 [details, diff] diff PS1 based on colour, root, and remote Attached is a patch that differentiates PS1 based on: colour-capabilities, root-ness, and remote/local. The patch also colours the '@' symbol purple. Note that remote/local only detects SSH; I don't know how to detect other remote login stuff (since I don't use them).
irt comment #54 re (1): Sorry, can't see any motivation behind this; smells like another "doing-things-different-than-anyone-else-for-no-apparent-reason-just-for-the-sake-of-doing-things-differently" sort of thing used to annoy sys-admins. There are also technical reasons why this may/will turn out to be a bad idea; BUT: since I'm on vacation, my motivation to fight over this is next to 0 at this time (sorry, maybe later). re (2): Don't know the previous situation for non-bash shells (haven't used vanilla baselayout in a very long time) but as it is now, PS1 assigned if $BASH_VERSION is unset is heavily bash-specific and expands to "u@h w $ " (minus the quotes). Only character recognized by ksh after the usual var, command and arithmetic substitutions is '!', replaced with current command number. re (3): Of course they do; all interactive bourne compatible shells, including bash in POSIX mode, read whatever file $ENV referes to (usually set in /etc/profile or .~/profile, after detecting shell it runs in), btw. in case of ksh traditionally ~/.kshrc, which traditionally sources /etc/ksh.kshrc (see the pattern?) to pick up global stuff)
So, it's because of this 'fix' that the default root PS1 isn't red anymore? I find that to be a major nuisance, since it makes it a lot more difficult to see the root consoles while flipping through tabs.
Pat (comment 58), I fixed that problem (see bug 59768). Sorry for the inconvenience. You can either remerge bash or copy the bashrc from app-shells/bash/files to /etc/bash Hans (comment 57), regarding point 2, you're not reading the profile correctly. Non-bash shells get PS1="`whoami`@`uname -n | cut -f1 -d.` \$ ".
You're right, but the problem is my non-bash shell didn't read it right either, just not in the same way I did; and actually displayed 'u@h w $ ' for its primary prompt. The problem appears to be if ash/dash/ksh are launched as an interactive nonlogin shell from whithin bash, they inherit bash's PS1 (consequence of nitpick 3); I don't think there's much you can do about that except move those other shell's PS1 to the right place too; one more reason those other shells should be more integrated into baselayout (there can be only one /etc/profile). I would propose nitpick 2 and nitpick 3 to be merged until more info is available.
Well... "nitpick 2" is actually the easiest to solve...just don't place `PS1' in the environment.
BAM!!! (and wb?) Checked my SuSE-9.0 and RH CDs and they don't exprot PS1 either. New proposal: Change nitpick 2 to: "Don't export PS1!"
I agree with that entirely. I really dislike exporting PS1 anyway. Fixed in rc-scripts cvs and in bashrc (I haven't bumped the bash revision for this minor change). Thanks guys. I always try to imagine what is going through Hans' head when he writes "BAM!!!" :-)
<disclaimer>I'm an extremely foul mood and should probably not be posting right now</disclaimer> The default ~/.bashrc is fucking up. Plain and simple. It's got a test in for interactive. .bashrc _SHOULD NEVER_ produce any output. This interactivity test is stupid and silly and just generally BREAKS THINGS. Take for example a non-interactive ssh login session: svn checkout svn+ssh://foo/bar Now, if there is some kind of svn wrapper script it will not get executed (The recommended way for setting up a specific umask). The same retartedness applies for /usr/local/{bin,sbin} which is only in PATH for _interactive_ login shells at this point in time. This is BROKEN. Now since nobody seems to give a flying shit about the correct way of doing things, I'll just keep on ranting and the STFU. Please see my comments earlier in this thread and if someone disagrees with that. PLEASE GIVE REASONS WHY THAT IS THE WRONG WAY OF DOING THINGS. Hacking out all your interactivity tests makes things work in a much more sane way. Emulating bugs in kdm so that the rest of us can feel that retartedness as well isn't sitting well with me at the moment. The way it's currently set up I must set up my PATH variable both in .bashrc as well as .bash_profile (by default, without hacking out interactivity tests), whilst I should only be required to set this in .bashrc. Ag wtf do I even bother ... someone just please re-open this bug or I will file another bug report that just complains about exactly the same thing.
(In reply to comment #64) > <disclaimer>I'm an extremely foul mood and should probably not be > posting right now</disclaimer> I'm interested in doing things the right way, but I'm not convinced you know what you're talking about, and I'm not willing to wade through your obscenities to make certain. Calm down and try again.
See comment 29.
(In reply to comment #66) > See comment 29. Thanks. My understanding is this: - our bash patches cause /etc/bash/bashrc to be sourced unconditionally - instead, you would like the skel/bashrc to source /etc/bash/bashrc explicitly so that it can be shut off by the user This has been batted around and decision was to leave the power in the hands of the system administrator. The reasoning is that: With the current bash SYS_BASHRC compile-time configuration, the system administrator could move /etc/bash/bashrc to (something like) /etc/bash/bashrc.include, then source it from skel/bashrc. That would accomplish what you're asking. However if the bash compile-time configuration were changed, there would be no way for the system administrator to achieve the current behavior without a custom ebuild. So the current behavior gives the administrator more power. Am I misunderstanding? Is there more you would like changed than what I've said?
Your argument is fair enough. I'll concede that there might be uses there, but I just don't see any situation where I would want that behaviour. And considering I've got my LPIC-2 and have about 2 years worth of extreme experience running university linux labs (400+ Linux PCs, 12 servers) I reckon that should count for something. I'm also pretty sure that I'm probably missing something, so an example of where you don't want to give the user the ability to bypass /etc/bash/bashrc would be uber cool. The same argument applies to /etc/bash/bash_logout. However, there are still problems with the default bash install: jkroon@pug ~ $ ssh root@xacatecas.lan echo '${PATH}' /usr/bin:/bin:/usr/sbin:/sbin jkroon@pug ~ $ ssh root@xacatecas.lan Last login: Tue Apr 4 22:23:26 2006 from pug.lan xacatecas ~ # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3.6:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/var/qmail/bin xacatecas ~ # That breaks any wrappers (for example svn, rsync, scp, sftp) one may have in /usr/local/bin, the svn example caused me one hell of a headache last year. Specifically, the assumptions as with regards to what gets sourced when is wrong (based on the comment in the default bashrc and profile files). Basically: interactive login shell: /etc/profile + ~/.bash_profile non-interactive login shell: ~/.bashrc interactive shell: ~/.bashrc subshell: ${BASHRC} - iirc, and only if set. interactive login shells include those spawned by xdm/gdm to spawn user WMs. kdm doesn't (didn't) do this due to a long-standing bug (it just runs the WM directly instead of execve'ing to the users (${SHELL} -l -c /path/to/wm). Some people claim it has been fixed recently and others simply claim it isn't a bug. And obviously with the current setup, /etc/bash/bashrc whenever I mention ~/.bashrc. Ok, so we know the default Gentoo bash setup breaks the PATH var. Basically, /etc/profile should source /etc/bash/bashrc, which _should_not_ have the interactivity test, or if you absolutely insist on having it there (I'll grant that it makes sense to not set PS1), only after the environment has been configured. The PATH should also be set in bashrc, not profile. Which is where it is currently set. The same argument applies to JAVA_HOME and just about every other environment variable configured from env.d, possibly to some scripts from /etc/profile.d as well. Haven't checked those though, the only one I care about is bash-completion and that only makes sense on interactive shells. Since GDM handles the situation correctly my environment for that gets set up correctly upon login so my interactive shells are good by default. In the case of /etc/profile and ~/.bash_profile it gets sourced in that specific order. Does the same hold for /etc/bash/bashrc and ~/.bashrc? Is this part of some standard somewhere? Also, does it really only make sense to do this in bashrc: shopt -s checkwinsize how about ssh sessions? These will source profile if/when logging in interactively. I don't see this happening in /etc/profile, nor do i see it sourcing bashrc. Or is the compile-time option of such a nature that bashrc _always_ gets sourced?
Another example that may illustrate that this problem is far bigger than simply /usr/local/bin: jkroon@pitchblack ~ $ ssh -X jkroon@192.168.1.8 konqueror bash: konqueror: command not found jkroon@pitchblack ~ $ ssh -X jkroon@192.168.1.8 Last login: Thu Apr 13 07:46:53 2006 from ixii.netronome.co.za jkroon@kobalt ~ $ konqueror X Error: BadAtom (invalid Atom parameter) 5 Major opcode: 20 Minor opcode: 0 Resource id: 0x122 It keeps on vomitting for a while and then proceeds to display in any case. Point being that even default-installed applications suffer from this.
