[Bug 244788] New: bashrc incorrectly calls login profile
https://bugzilla.novell.com/show_bug.cgi?id=244788 Summary: bashrc incorrectly calls login profile Product: openSUSE 10.2 Version: Final Platform: i686 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: suse@tlinx.org QAContact: qa@suse.de "profile" and "profile.d" are for login scripts run for interactive sessions "bashrc" is run on each bash invocation in 10.2 someone added code in /etc/bash.bashrc to call the login /etc/profile This is not correct usage. Code added (and comment): # # Just in case the user excutes a command with ssh # if test -n "$SSH_CLIENT" -a -z "$PROFILEREAD" ; then . /etc/profile > /dev/null 2>&1 fi ----- Note, this wouldn't get called with "rsh" (assuming someone used it; but it does get called on "scp" and "rsync" (assuming one uses 'ssh as transfer method'); just as .bashrc is reserved for per-bash invokes, so, by its name should be /etc/bash.bashrc --the problem is that /etc/bash.bashrc calls the user's locally defined bashrc.local -- As per bash documentation, I do interactive initializations in my "profile" and do per-invok initializations in bashrc (which means "profile" calls bashrc, but bashrc doesn't call profile); interactive invocations do things like set tty values and unicode terminal values. These are things that don't work correctly unless a tty has been allocated (as in an interactive login). bashrc needs to be kept for non-interactive login initializations -- and NOT call "profile" (which is reserved for activating tty sessions that record logins in 'last'). Please don't mix these conventions...I know someone thought they were helping, but in my case, it ended up calling my 'login' initializations twice. I specifically DO NOT check for my login script being called twice because it "should" only be called once (whereas my bashrc does check for duplicate/recursive calls, as it may be called more than once). Thanks, Linda -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 judas_iscariote@shorewall.net changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |werner@novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org ------- Comment #1 from werner@novell.com 2007-02-13 09:32 MST ------- The shell started by the ssh on the remote system is not a login shell, therefore this piece of code is correct on the remote system, due it provides the full environment, e.g. path, on the remote system. This piece does nothing on the local system. Beside this the /etc/profile is written in the manner that it can also be sourced by non-interactive shells by testing on $PS1 and the terminal line if any. The last record is written by login or xdm/ksm/gdm or any other login program and never by /etc/profile (this would be a real bug IMHO) Please note that I will not remove this code. This because it solves a lot of trouble, e.g. user expecting that their applications on the remote system will be started out from the remote system path. At last but not least I'd like to know _why_ your personal profile is sourced twice on the remote system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 suse@tlinx.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|suse@tlinx.org | ------- Comment #2 from suse@tlinx.org 2007-02-14 20:29 MST ------- Reasons for "fixing" this. 1) bash manpage documents taht "/etc/profile" is only called by interactive login shells ; the standard behavior of bash is broken 2) bash manpage says "bashrc" is called on "interactive sessions" that _are not login sessions_ I'm using the fact that profile is called for interactive login and not during a non-login session to do one-time, login-only initializations AND that bashrc is called _instead_ profile to do "within-same-login-session" special handling that I don't want done if it is not a new login session. This is all documented behavior in the bash man page. My same scripts work across IRIX, Suse 9.x,Suse 10.x and Windows(cygwin) (and prevously, Solaris). These all work without specific checks to OS names or versions. The SuSE 10.x change makes the behavior incompatible with IRIX, POSIX(cygwin), previous versions of SuSE and most likely Solaris (can't check it right now). I'd already setup modular files to allow setting: - one-time login variables & accounting - per-invok variables, common bash code and aliases I'd also have gone to some lengths to make sure I use minimal non-builtins and utils that might cause delays or generate errors if called in the wrong execution path. As to why some things are called twice -- both "profile and bashrc" call a "common" file in addition to their specific initializations. Also, there are login things done once/login session, but not called during non-interactive "logins". The problem this new change has created is that profile gets called during non-interactive logins which goes against bash's documented behavior. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org ------- Comment #3 from werner@novell.com 2007-02-15 03:41 MST ------- IMHO ... the current standard behaviour of the bash is somewhat broken without this change. I've get a large numbers of reports that the path after a `slogin host.remote' or `ssh host.remote' the system PATH environment variable from the remote among other environment variables is not provided. Most people do not use the fulls path for e.g. xemacs or an kde application but only the basename even with a non-interactive ssh usage. This does not happen on the local system because after login (/bin/login or xdm/kdm/gdm) the /etc/profile was sourced by the bash. All processes afterwards have the full environment of the local system. Now after doing a `slogin host.remote' the remote system environment was never set because the ssh daemon does not a real login even if the ssh command is called a slogin. Beside this sourcing /etc/bash.bashrc only for non-login but interactive bash processes was also the cause of a large numbers of reports within my bugzilla and mail folder. One reason for souring the /etc/bash.bashrc within /etc/profile not only on SuSE. Currently I've done the setup in this a way that system environment is exported in /etc/profile or /etc/csh.login for tcsh users at login and afterwards not exported things like aliases and prompts are set by /etc/bash.bashrc or /etc/csh.cshrc for tcsh users. To solve the problem of missing the system environment for an ssh login the /etc/bash.bashrc and the /etc/csh.cshrc test about the exported readonly variable which is set by souring /etc/profile (PROFILEREAD) respectivly by souring /etc/csh.login (CSHRCREAD) for an ssh session only and if those variables are not set they source the system environment aka /etc/profile respectivly /etc/csh.login. Please see that the files /etc/profile respectivly /etc/csh.login also include the environment provided by /etc/profile.d/*.sh and /etc/profile.d/*.csh provided by all packages using environment variables . as you may understand I'd like not to loose this by removing the lines in /etc/bash.bashrc you mentioned nor in /etc/csh.cshrc. One suggestion about the problem of sourcing files twice is to use an exported readonly variable. This I'm using because there are many users out there which do source /etc/profile within their ~/.bashrc due to mentioned problem above. This had caused a lot of trouble by sourcing things twice or within loops. This might be also an option to solve your problem I've caused with this change. That is the possiblity to add some bourne shell code to your files which should work on all systems. For sourced only bourne shell file this may look like test -z "$MYFILERAD" || return readonly MYFILERAD=true export MYFILERAD what do you think about this? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 suse@tlinx.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|suse@tlinx.org | ------- Comment #4 from suse@tlinx.org 2007-02-17 17:22 MST ------- The behavior of bash conforms to the standard, listed behavior of "bash" ( :-) ). Saying it is "broken" is a matter of being able to read the manpage or not. I had problems at some point in the past with wanting variables initialized no matter what the session. I read the manpage rather than filing a bug against SuSE's bash and adopted my scripts to work with the documented behavior. Note at this point -- it's not that I cannot figure out a way _around_ SuSE's non-standard behavior. I to have variables in my init files to detect when I've already called my scripts or not. It's that SuSE is breaking documented compatibility. I understand the need to have a common setup for variables. I chose to do this with an explicitly named "common.sh" called by both. The problem created by the SuSE solution is that in addition to setting up session variables, it is also calling the user's "/etc/profile.local" -- thus doing the users "per-login" initialization more than once. I also have a similar call to "profile" from my system's local "bashrc" -- I make sure the "per-login" variables are set in my /etc/bashrc.local and if not, I call my /etc/profile.local script. However, in my case -- my local "profile" script does things only intended to be called once/login. Variables and settings that need to be set for both "bashrc" and "profile" are in the "common" file and are only called once. Thus I solve my need for both per-login settings and having one place for common settings. Having bashrc call profile to set "common settings" has unwanted side effects of also calling any -per-login processing. I could see it being more of a problem if someone relied on "bash_logoff" to be called at end of any session started with "profile" (as is would be normal if profile was only called for login sessions). In a way, SuSE is "dumbing down" "bash" because people are too lazy or ignorant to do things "right" -- yeah, makes it easy for the typical "Microsoft" type user who is computer illiterate, but then it bites people who bothered to read the manual (almost never a "Good Thing"). Hopefully this points to a backwards compatible way to make everybody happy (other than anyone who has to implement and test the change :-)). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org ------- Comment #5 from werner@novell.com 2007-02-19 03:16 MST ------- The order for me is at first security, at second the users, and at third the standard ;) In other words, I'll not tell the user to read the manual page if he/she is not willingly to do :| But I'm willingly to add a SSH_SOURCE_THE_PROFILE to /etc/sysconfig/suseconfig with default to "yes" and you're welcomne to change this to "no". Nevertheless any report from a system using "no" that the ssh does not wokr as expected will be ignored ;) ... beside this I'm also willingly skip the second reading /etc/profile.local if and only if sourced by /etc/bash.bashrc aka ssh. Which points of the previous paragraph would fit your needs and/or your opinion? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #6 from suse@tlinx.org 2007-02-21 17:49 MST ------- Hmmm...looking over this I haven't come to a conclusion of the correct choice. Something that is not clear to me -- where is "/etc/bash.bashrc" getting called from, anyway? It doesn't seem to be referenced as being called by ssh[d] or bash. It doesn't seem to have pointed ENV or BASH_ENV at "itself"... Is intended to be a "~/.bashrc" parallel that is called every time a new shell is started? I note you use "SSH_CLIENT". It isn't documented either. In looking through the openssh source I see the variable used, but marked "deprecated". I think you may want to replace its usage with "SSH_CONNECTION". But at this point -- the reason my vars are called twice is that my ".bashrc" calls my global "vars.sh". /etc/bash.bashrc calls profile-> profile.local->my vars.sh (indirectly). Before telling you one way or another -- I wanted to verify whatever I said would work! :-) But what's confusing me a bit is where and when /etc/bash.bashrc is called and if it is called before or after my local .bashrc. For users to set their environment, there already exist special "rc" files both system and user level) to allow them to set or call a variable setup. I'm not sure of backward compatibility impact, but that wasn't one of your listed concerns. But maybe you would want to provide a system-level sshrc file that would call a common-variable set routine. I resist it calling "/etc/profile", as that should be reserved for calling an interactive login session, IMO. So...called from where? How? /etc/bash.bashrc? I'm not seeing why it is even getting called at all (i.e. what program is calling it). If it is not meant to be invoked with every bash shell, is it only used or called by ssh? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 suse@tlinx.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|suse@tlinx.org | ------- Comment #7 from suse@tlinx.org 2007-02-22 20:24 MST ------- /etc/bash.bashrc is a build-time option in bash but is not documented in the manpages. Now the sequence is more clear /etc/bash.bashrc calls /etc/profile calls /etc/bash.bashrc (nested; which realizes it's in a nested call 95% the way through, when it doesn't call profile again) profile calls users HOME/.bashrc then bash calls users ~/.bashrc for non-interactive session So in non-interactive sessions, a users home-.bashrc is called twice -- that's seems to be the problem here in this situation. Perhaps .profile should check if it is NOT in an interactive session, then don't call ".bashrc" because bash calls it by default. There is also alot of wasted code in bash.bashrc -- it defines aliases for non-interactive sessions. Unless "shopt expand_aliases" is set to true (defaults to off), aliases are not expanded in non-interactive shells. There is also a bunch of code to set the prompt for non-interactive prompts. Why? The minimum that needs to be fixed is ".profile" being responsible for calling bashrc "twice". But having nested recursive calls that don't determine "nestedness" until 95% through is awfully inefficient. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #8 from werner@novell.com 2007-02-23 06:54 MST ------- The interactive code is only used for case "$-" in *i*) : interactive bash code esac see manual page of bash the first few lines after INVOCATION, an interactive bash knows about PS1 and includes ?i' within $-. The double sourcing in case of ssh connection I'v dectected a few days ago ... I'd like to use a control variable within /etc/bash.bashrc to avoid double souring of /etc/bash.bashrc within /etc/profile. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #9 from werner@novell.com 2007-02-26 08:24 MST ------- I've fixed the double souring for the next release of openSuSE 10.3. Hopefully this fix this bugzilla ... the method is if test -n "$SSH_CONNECTION" -a -z "$PROFILEREAD" ; then _SOURCED_FOR_SSH=true . /etc/profile > /dev/null 2>&1 unset _SOURCED_FOR_SSH fi in /etc/bash.bashrc and if test "$is" != ksh -a -z "$_SOURCED_FOR_SSH" ; then test -r /etc/bash.bashrc && . /etc/bash.bashrc fi in /etc/profile -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 suse@tlinx.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #10 from suse@tlinx.org 2007-03-09 17:31 MST ------- Sorry to take time to test this -- I "virtually" always have too much on plate, so timeslicing takes a bit -- (keep waiting for brain-hardware update, but ...) The above doesn't fix my problem but could with a minor "tweak". specifically, in /etc/profile, the conditional for being in SSH needs to be around not just the call the "/etc/bash.bashrc", but also around the _user's_ ".bashrc" (and likely need the logic to encompass the following calls to the ksh equivalents. I.e. looks like you added "+" replacing "-" lines; other lines included for context # System BASH specials, maybe also good for other shells # Note that ksh always reads /etc/ksh.kshrc # + if test "$is" != ksh -a -z "$_SOURCED_FOR_SSH" ; then + test -r /etc/bash.bashrc && . /etc/bash.bashrc + fi # (replacing) - if test "$is" != ksh -a -r /etc/bash.bashrc ; then - . /etc/bash.bashrc - fi if test "$is" = "bash" -a -z "$_HOMEBASHRC" ; then # loop detection readonly _HOMEBASHRC=true test -r $HOME/.bashrc && . $HOME/.bashrc .. ----------- But, you need to have your above logic also blocking a redundant call to the users ".bashrc", and you need to also make sure that the same checks are done for the ksh users -- so something like this: if -z "$_SOURCED_FOR_SSH"; then # # System BASH specials, maybe also good for other shells # Note that ksh always reads /etc/ksh.kshrc # if test "$is" != ksh ; then test -r /etc/bash.bashrc && . /etc/bash.bashrc if test "$is" = "bash" -a -z "$_HOMEBASHRC" ; then # loop detection readonly _HOMEBASHRC=true test -r $HOME/.bashrc && . $HOME/.bashrc fi fi -------- I put "SOURCED_FOR_SSH" as a separate test and was going to have the ".kshrc" code also not called when sourced from SSH -- seems like it would make parallel sense, but the ksh logic is different from the bash logic, so the same fix might not work for ksh. -l -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 burnus@gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus@gmx.de ------- Comment #11 from burnus@gmx.de 2007-03-10 07:45 MST ------- Is the fix of this bug, aaa_base-10.3-15 * Mo Feb 26 2007 - werner@suse.de - Do not source bashrc twice if sourcing profile for ssh (#244788) , is the reason for me having always to do . .bashrc when I log in to my server from my laptop via ssh? If yes, then I don't like the fix. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #12 from werner@novell.com 2007-03-12 03:02 MST ------- @Tobias: The latest aaa_base includes the following: ------------------------------------------------------------------- Tue Feb 27 17:55:33 CET 2007 - werner@suse.de - Oops, check also for profile within bashrc before assuming the default behaviour of the bash (#244788) ------------------------------------------------------------------- Mon Feb 26 16:06:05 CET 2007 - werner@suse.de - Do not source bashrc twice if sourcing profile for ssh (#244788) - Expand local ./files for manual pages within bash (#248865) ------------------------------------------------------------------- which means that ~/.bashrc should sourced as well. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
@Tobias: The latest aaa_base includes the following [...] which means that ~/.bashrc should sourced as well. I have that version (up to Wed Mar 07 2007 - werner@suse.de - Use colored root
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #13 from burnus@gmx.de 2007-03-12 10:42 MST ------- (In reply to comment #12) prompt), but if I do: ssh my.server.net I still have to source ~/.bash manually. :-( -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Comment #14 from werner@novell.com 2007-03-13 05:03 MST ------- Hopefully fixed. I've run some tests with bash, ash, ksh, and zsh, with and without ssh login and ssh command, also `su' and `su -', and at last but not least chroot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 suse@tlinx.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #15 from suse@tlinx.org 2007-03-13 10:28 MST ------- Q: does "~/.bashrc still get called twice? The test for being within didn't encompass ~/.bashrc as it did "bash.bashrc". The calling of .bashrc twice upon a non-login ssh session is specifically what was causing my probs. ** Is it possible to attach the updated files to this bug for further testing? Tobias, question -- you want your local .bashrc called not only for non-logic shells, but also for login shells, yes? Is there something that would preclude you adding automating your sourcing of the file, upon login, by including it in the and of the login personalization files: ~/.bash_profile, ~/.bash_login, or ~/.profile? If you are only wanting "~/.bashrc" sourced for ssh logins, there is also "~/.ssh/rc". I wasn't clear why you hadn't automated sourcing ".bashrc" in your login script? If you are used to bash across multiple systems, .bashrc is only called at login if explicitly chosen (it's not the default). It maybe be called by the users .profile or from the system /etc/profile. Maybe that would work as a solution for here? If SuSE added a "~/.profile" to new users' home dirs that tested for and called .bashrc for users, that would provide a compatible way for user's to have their .bashrc called on login as well as non-login shells? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #16 from werner@novell.com 2007-03-13 10:34 MST ------- Created an attachment (id=124112) --> (https://bugzilla.novell.com/attachment.cgi?id=124112&action=view) Tar file profile.tar.bz2 which includes etc/profile etc/bash.bashrc -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #17 from werner@novell.com 2007-03-13 10:36 MST ------- I'd like not to overwrite the users ~/.profile not ~/.bashrc. For testing see attachment #124112 within comment #16 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #18 from burnus@gmx.de 2007-03-13 11:21 MST -------
Tobias, question -- you want your local .bashrc called not only for non-logic shells, but also for login shells, yes?
Yes, I would like to have it included for both login shells and non-login shells. Not that I cannot change my files. Quoting from ~/.bashrc (based on /etc/skel/.bashrc): # There are 3 different types of shells in bash: the login shell, normal shell # and interactive shell. Login shells read ~/.profile and interactive shells # read ~/.bashrc; in our setup, /etc/profile sources ~/.bashrc - thus all # settings made here will also take effect in a login shell.
I'd like not to overwrite the users ~/.profile not ~/.bashrc. Thanks, Werner :-)
I'm sure that this change will break several user installations. I know some post-installation scripts which simply add things to ~/.bashrc and not to ~/.profile. And even in the current version the skel file claims that .bashrc is also read for login shells. If you plan to change this, please put a HUGE notice in the release notes and change the skel/.bashrc file. Note in the release notes also how to get the old behaviour back. On single-user installations, the user will probably change his ~/.??* files. But for for big user installations, the administrator surely wants to have the old behaviour instead of dealing with 1000 users of whose 200 have all of a sudden a problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #19 from suse@tlinx.org 2007-03-13 20:55 MST ------- Tobias, please note -- the comments in /etc/skel/.bashrc are not necessarily portable from release to release nor to other environments. Those comments are not part of the standard "bash" distribution. I've used bash on Irix, Redhat, Mandrake, Windows with Microsoft's POSIX compatible subsystem and with Cygwin. You can rely on .bashrc being called from /etc/profile for now, but it is not standard usage. For myself, I already do something similar, but have my /etc/profile.local and my local ~/.bashrc both call common initialization files. This works in a heterogeneous environment. The problem recently has to do with /etc/bash.bashrc calling /etc/profile which has ended up calling the users ~/.bashrc twice. I got bitten by this change in non-interactive "ssh" sessions (i.e. it shouldn't have affected interactive, login sessions). But because my local .bashrc was called twice I got errors on non-interactive ssh. Example: ishtar:law> ssh astara echo hi /etc/local/vars.sh: line 46: typeset: _prg_tty: readonly variable /etc/local/vars.sh: line 49: typeset: _prg_id: readonly variable /etc/local/vars.sh: line 54: _sh_interactive_shell: readonly variable /etc/local/vars.sh: line 72: typeset: USER: readonly variable /etc/local/vars.sh: line 77: typeset: _sh_LOGNAME_: readonly variable /etc/local/vars.sh: line 78: typeset: LOGNAME: readonly variable /etc/local/vars.sh: line 81: unset: HOME: cannot unset: readonly variable /etc/local/vars.sh: line 82: typeset: HOME: readonly variable /etc/local/vars.sh: line 201: typeset: _vars_read_: readonly variable /etc/local/vars.sh: line 203: typeset: PERL5LIB: readonly variable hi My suggestion on modifying "~/.profile" was concerning _new_ users -- not existing ones, so it wouldn't modify existing .profile settings and users would continue to get behavior they were already used to. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #20 from suse@tlinx.org 2007-03-13 20:59 MST ------- Tobias, please note -- the comments in /etc/skel/.bashrc are not necessarily portable from release to release nor to other environments. Those comments are not part of the standard "bash" distribution. I've used bash on Irix, Redhat, Mandrake, Windows with Microsoft's POSIX compatible subsystem and with Cygwin. You can rely on .bashrc being called from /etc/profile for now, but it is not standard usage. For myself, I already do something similar, but have my /etc/profile.local and my local ~/.bashrc both call common initialization files. This works in a heterogeneous environment. The problem recently has to do with /etc/bash.bashrc calling /etc/profile which has ended up calling the users ~/.bashrc twice. I got bitten by this change in non-interactive "ssh" sessions (i.e. it shouldn't have affected interactive, login sessions). But because my local .bashrc was called twice I got errors on non-interactive ssh. Example: ishtar:law> ssh astara echo hi /etc/local/vars.sh: line 46: typeset: _prg_tty: readonly variable /etc/local/vars.sh: line 49: typeset: _prg_id: readonly variable /etc/local/vars.sh: line 54: _sh_interactive_shell: readonly variable /etc/local/vars.sh: line 72: typeset: USER: readonly variable /etc/local/vars.sh: line 77: typeset: _sh_LOGNAME_: readonly variable /etc/local/vars.sh: line 78: typeset: LOGNAME: readonly variable /etc/local/vars.sh: line 81: unset: HOME: cannot unset: readonly variable /etc/local/vars.sh: line 82: typeset: HOME: readonly variable /etc/local/vars.sh: line 201: typeset: _vars_read_: readonly variable /etc/local/vars.sh: line 203: typeset: PERL5LIB: readonly variable hi My suggestion on modifying "~/.profile" was concerning _new_ users -- not existing ones, so it wouldn't modify existing .profile settings and users would continue to get behavior they were already used to. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 ------- Comment #21 from suse@tlinx.org 2007-03-13 21:02 MST ------- FWIW, the latest attached patch DOES NOT exhibit the problem behavior mentioned above (i.e. works for me! :-)). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |burnus@gmx.de ------- Comment #22 from werner@novell.com 2007-03-14 03:36 MST ------- Now the remaining question is if the attached files also solve the problem mentioned by Tobias. Tobias? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 burnus@gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED Info Provider|burnus@gmx.de | ------- Comment #23 from burnus@gmx.de 2007-03-16 08:52 MST -------
Now the remaining question is if the attached files also solve the problem mentioned by Tobias. Tobias? Yes. It solves my problem.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Comment #24 from werner@novell.com 2007-03-16 09:00 MST ------- OK, hopefully fixed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply＠novell.com