http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 Christian Herenz changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1004769 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 http://bugzilla.opensuse.org/show_bug.cgi?id=1078124#c1 Christian Herenz changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Major --- Comment #1 from Christian Herenz --- Here is some additional information - from the bash manpage that is shipped in opensuse: When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The SLES 11 documentation also states clearly that .profile is invoked in login shells, and .bashrc in non-login shells. https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_adm_whatis... However, openSUSE does in fact not make this distinction. The default .bashrc file openSUSE puts in a users directory states at the beginning:

# 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.

Therefore, there is no way to use .bashrc in its intended way, as a configuration file for interactive non-login shells, as all changes made to .bashrc will also affect login shells. I also tried to find how this is implementeted: The relevant part in /etc/profile is: if test -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 -a "$is" != zsh ; then test -r /etc/bash.bashrc && . /etc/bash.bashrc fi if test -n "$restricted" ; then readonly _HOMEBASHRC=true fi if test "$is" = "bash" -a -z "$_HOMEBASHRC" ; then # loop detection readonly _HOMEBASHRC=true test -r $HOME/.bashrc && . $HOME/.bashrc fi The variable $_SOURCED_FOR_SSH is defined from /etc/bash.bashrc: if test \( -n "$SSH_CONNECTION" -o -n "$SUDO_COMMAND" \) -a -z "$PROFILEREAD" ; then _SOURCED_FOR_SSH=true . /etc/profile > /dev/null 2>&1 unset _SOURCED_FOR_SSH fi So, if I understand above logic correctly, ${HOME}/.bashrc is always sourced in /etc/profile, except when connecting via SSH or doing a sudo (cases which will invoke /etc/bash.bashrc). Thus in a standard non-login shell "test -z "$_SOURCED_FOR_SSH" " evaluates to true and ~/.bashrc is sourced. Best regards, Christian -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 http://bugzilla.opensuse.org/show_bug.cgi?id=1078124#c3 --- Comment #3 from Christian Herenz --- More information on the expected behaviour when calling `bash --login`: https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html "When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. " This design is done on purpose, and sourcing ${HOME}/.bashrc can have unwanted consequences. While the standard ${HOME}/.bashrc from /etc/skel provides the information that openSUSE behaves differently, this behaviour is not necessary and can lead to unwanted consequences. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 http://bugzilla.opensuse.org/show_bug.cgi?id=1078124#c5 Jon Brightwell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ro@suse.com --- Comment #5 from Jon Brightwell --- CC ro@suse as an aaa_base dev -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 http://bugzilla.opensuse.org/show_bug.cgi?id=1078124#c9 --- Comment #9 from Christian Herenz --- Sorry, your argument about other users opening bugs, which can clearly resolved by pointing to the relevant with a WONTFIX, makes absolutely no sense to me. Right now opensuse does it in a way that is clearly not documented (only in the /etc/skel/.bashrc) - all other documentation that (bash manpage, bash manual, SLES documentation) clearly outlines how it should work. Of course there is an workaround for your abuse of ~/.bashrc as a configuration file, something like [ -z "$PS1" ] && return -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 http://bugzilla.opensuse.org/show_bug.cgi?id=1078124#c11 --- Comment #11 from Christian Herenz --- Note that openSUSE'ism does not necessary mean a bad thing. In fact, I guess the way that .profile .bashrc .bash_login and .bash_profile work is quite complicated to understand, and most users don't have a clue. Have a look at this simple viewgraph here :-) https://www.cyberciti.biz/media/new/cms/2015/01/BashStartupfiles.jpg I will try this mailinglist thing later, but in the meantime openSUSE users wanting to use anaconda, need to do something different than the rest of the world. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1078124 http://bugzilla.opensuse.org/show_bug.cgi?id=1078124#c14 --- Comment #14 from Dr. Werner Fink --- (In reply to Keith Hizal from comment #13)

I'm not sure if this is a side effect of this bug or not, but attempting to put "exec fish" into the bashrc causes no desktop environment to load, Xorg or Wayland.

Ahmm ... why you're breaking the bash start/login chain? There is always a method to break a system yes. If you want an other use shell then please use the system tools which are /etc/shells (see man 5 shell) and the command chsh (see man 1 chsh). See the scripts below /etc/X11/xdm for usage of exec within (ba)sh code to either handle file descriptors or replace the current shell with an other final program. -- You are receiving this mail because: You are on the CC list for the bug.