[Bug 1219979] New: Bash exported function are renamed internally then are ignored by Systemd - Kde desktop
https://bugzilla.suse.com/show_bug.cgi?id=1219979 Bug ID: 1219979 Summary: Bash exported function are renamed internally then are ignored by Systemd - Kde desktop Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: jcdole@free.fr QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- I have bash definition functions and variables that are sourced from /etc/profile.d (case 1) or from ~/.profile (case 2) In case 1, journald show : Feb 15 17:13:55 15-4---G731GV-VM-04 startplasma-x11[1725]: Skipping syncing of environment variable "BASH_FUNC__MY_ECHO_%%" as name contains unsupported characters None of my function are exported to user environment. None of my functions use the double characters '%%' I have environment variables that defined colors : MY_LIGHT_RED=$'\e[1;31m' Journald show : Feb 15 17:13:55 15-4---G731GV-VM-04 startplasma-x11[1725]: Skipping syncing of environment variable "MY_LIGHT_RED" as value contains unsupported characters These colors definition are not exported to user environment. In case 2, journald show the same errors but in this case functions and env var are exported to the user environment. Any help is very welcome. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c1 Dirk Weber <d_werner@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |d_werner@gmx.net --- Comment #1 from Dirk Weber <d_werner@gmx.net> --- Just for information: this is basically the same problem as described by bug 1203617. Short summary: such functions should not be defined in the profile (/etc/profile.d or ~/.profile ) but in bashrc (/etc/bash.bashrc.local, ~/.bashrc) which are intended for interactive shells. In your case with local adaptations you can just move the definitions there. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 Vadim Krevs <vkrevs@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vkrevs@yahoo.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c3 --- Comment #3 from Jean-Claude Dole <jcdole@free.fr> --- Following comment 1 I put initialization in /etc/bash.bashrc.local There is a problem. Any times user open a new konsole from the application launcher, function definition are lost in the new konsole. Function definitions seems not inherited from the parent environnement. But Env var still be defined. Any advices are welcome. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c4 --- Comment #4 from Dirk Weber <d_werner@gmx.net> --- My analysis and tests have mainly been in the scope of bug 1203617 and with the "mc" function. Both inclusion in /etc/bash.bashrc.local and $HOME/.bashrc result in providing the function "mc" as desired in "konsole" started from the application launcher on my systems. The BASH_FUNC_mc%% from the standard sourcing of /etc/profile.d/mc.sh still exists, but additionally the function "mc" is defined from sourcing either /etc/bash.bashrc.local or $HOME/.bashrc: When defined in ~/.bashrc I get in a newly started konsole: $ env |grep -A1 mc BASH_FUNC_mc%%=() { . /usr/share/mc/mc-wrapper.sh } $ type mc mc is a function mc () { . /usr/share/mc/mc-wrapper.sh } ------- Also when defined in /etc/bash.bashrc.local I get in a newly started konsole: $ grep mc /etc/bash.bashrc.local [ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh || true $ type mc mc is a function mc () { . /usr/share/mc/mc-wrapper.sh } $ env |grep -A1 mc BASH_FUNC_mc%%=() { . /usr/share/mc/mc-wrapper.sh } The behavior is as desired - the function "mc" replaces the call of /usr/bin/mc when starting mc on the command line. I assume you are using bash and not some other shell which might not be sourcing /etc/bash.bashrc.local or $HOME/.bashrc? Maybe you have some mechanism in place which prohibits the settings, like $HOME/.bash.expert ? Or you have a configuration in konsole causing bash to be started as login shell? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c5 --- Comment #5 from Jean-Claude Dole <jcdole@free.fr> --- Thank you very much for taking the time to answer me. Rightly or wrongly, for years I have been using the following piece of code (or somethings similar) to make variables and function definitions accessible to everyone: ----> if test -z "$SOURCED_SYS_COMMON_VAR" ; then test -s /backup_sys/VAR/MY_ENV_VAR/zzzz2_system_common_general_env_var_full.sh && . /backup_sys/VAR/MY_ENV_VAR/zzzz2_system_common_general_env_var_full.sh if [[ "$E_FILES_DIFFER" -ne 109 ]] ; then MY_LOGGER2_bash_bashrc_local "E_FILES_DIFFER -ne 109 --- COMMON VAR NOT SOURCED : zzzz2_system_common_general_env_var_full.sh" "0" else readonly SOURCED_SYS_COMMON_VAR=true export SOURCED_SYS_COMMON_VAR fi else MY_LOGGER2_bash_bashrc_local "COMMON VAR ALREADY SOURCED : zzzz2_system_common_general_env_var_full.sh" "5" fi if test -z "$SOURCED_SYS_COMMON_FUNC" ; then test -s /backup_sys/VAR/MY_ENV_VAR/zzzz1_system_common_function_full.sh && . /backup_sys/VAR/MY_ENV_VAR/zzzz1_system_common_function_full.sh if [[ -z "$(LC_ALL=C type stop_or_continue 2>/dev/null)" ]] ; then MY_LOGGER2_bash_bashrc_local "COMMON FUNC NOT SOURCED : zzzz1_system_common_function_full.sh" "0" else readonly SOURCED_SYS_COMMON_FUNC=true export SOURCED_SYS_COMMON_FUNC fi else MY_LOGGER2_bash_bashrc_local "COMMON FUNC ALREADY SOURCED : zzzz1_system_common_function_full.sh" "5" fi <---- That has worked for me from the old days up to 15.4 See screenshots : 15.1 https://paste.opensuse.org/pastes/d0119db2c2fa 15.4 https://paste.opensuse.org/pastes/c8b8584b73fd 15.5 and 15.6 same behaviour : Function definitions does not survive. https://paste.opensuse.org/pastes/86e970296d2c Konsole Opensuse for each test : Command : konsole Configuration : builtin So somethings has change since 15.5 You will notice that this only concerns function definitions. Of course if I remove the one-shot read >>> if test -z "$SOURCED_SYS_COMMON_FUNC" ; then <<< there is no problem but the files definitions are reread indefinitely. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c6 --- Comment #6 from Dr. Werner Fink <werner@suse.com> --- Exporting functions is a bash special feature* and not supported by any other shell or program like systemd and as all exported variables this belongs to /etc/profile, /etc/profile.local, and /etc/profile.d/*.sh Can we please stop misusing ~/.bashrc, /etc/bash.bashrc, and /etc/bash.bashrc.local for environment? Those are for interacive invocation only. As the the profile is sourced at login via e.g. (/usr)/etc/X11/xdm/Xsession in the exec_login() function to have the environmnet only once for the full login session. * werner@boole:~> xyz() { true; } werner@boole:~> export -f xyz werner@boole:~> printenv | grep xyz printenv | grep -A1 xyz BASH_FUNC_xyz%%=() { true } only bash knows about `export -f' and `BASH_FUNC_*%%=()' but not systemd -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c7 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #7 from Dr. Werner Fink <werner@suse.com> --- Just created on TW (should also work on Leap) a file localhost:~/Desktop # cat /etc/profile.d/testt.sh function xyz () { true } export -f xyz export testt=testt localhost:~/Desktop # then log out and log in again open a konsole and see localhost:~/Desktop # printenv | grep testt testt=testt localhost:~/Desktop # printenv | grep xyz BASH_FUNC_xyz%%=() { true and it works localhost:~/Desktop # set -x; xyz ; set +x + xyz + true + set +x it should be noted that I use the display-manager.service on that TW -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c8 --- Comment #8 from Jean-Claude Dole <jcdole@free.fr> --- (In reply to Dr. Werner Fink from comment #7)
Just created on TW (should also work on Leap) a file
localhost:~/Desktop # cat /etc/profile.d/testt.sh function xyz () { true } export -f xyz export testt=testt localhost:~/Desktop #
then log out and log in again open a konsole and see
localhost:~/Desktop # printenv | grep testt testt=testt localhost:~/Desktop # printenv | grep xyz BASH_FUNC_xyz%%=() { true
and it works
localhost:~/Desktop # set -x; xyz ; set +x + xyz + true + set +x
it should be noted that I use the display-manager.service on that TW
That does not work on a fresh install of leap 15.5 nor leap 15.6 Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "BASH_FUNC_stop_or_continue%%" as name contains unsupported characters Remark : None of my functions have a %% in their name. ------------------------------------------------------- Same kind error for environment variables : Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "MY_LIGHT_CYAN" as value contains unsupported characters MY_LIGHT_CYAN is defined like this MY_LIGHT_CYAN=$'\e[1;36m' or defined like this MY_LIGHT_CYAN=$'\e[1;36m' -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c9 --- Comment #9 from Jean-Claude Dole <jcdole@free.fr> --- (In reply to Dr. Werner Fink from comment #6)
Exporting functions is a bash special feature* and not supported by any other shell or program like systemd and as all exported variables this belongs to /etc/profile, /etc/profile.local, and /etc/profile.d/*.sh
Can we please stop misusing ~/.bashrc, /etc/bash.bashrc, and /etc/bash.bashrc.local for environment? Those are for interacive invocation only. As the the profile is sourced at login via e.g. (/usr)/etc/X11/xdm/Xsession in the exec_login() function to have the environmnet only once for the full login session.
* werner@boole:~> xyz() { true; } werner@boole:~> export -f xyz werner@boole:~> printenv | grep xyz printenv | grep -A1 xyz BASH_FUNC_xyz%%=() { true }
only bash knows about `export -f' and `BASH_FUNC_*%%=()' but not systemd
Following your comment I sourced my files definitions in : /etc/profile.d/*.sh --> that does not work /etc/profile.local/*.sh --> that does not work In each case same error : Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "BASH_FUNC_stop_or_continue%%" as name contains unsupported characters Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "MY_LIGHT_CYAN" as value contains unsupported characters -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c10 --- Comment #10 from Jean-Claude Dole <jcdole@free.fr> --- I would like to point out that you did not answer my question: "What changes Opensuse have made after version leap 15.4" On the other hand, in your remarks you refer to systemd. What systemd has to do with the Bash program. Regards -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c11 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Assignee|werner@suse.com |screening-team-bugs@suse.de Resolution|WORKSFORME |--- Summary|Bash exported function are |KDE plasma workspace |renamed internally then are |ignores special environment |ignored by Systemd - Kde |variables (Was: Bash |desktop |exported function are | |renamed internally then are | |ignored by Systemd - Kde | |desktop) CC| |alarrosa@suse.com, | |christophe@krop.fr, | |fabian@ritter-vogt.de, | |lbeltrame@kde.org, | |werner@suse.com --- Comment #11 from Dr. Werner Fink <werner@suse.com> --- (In reply to Jean-Claude Dole from comment #8)
That does not work on a fresh install of leap 15.5 nor leap 15.6 Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "BASH_FUNC_stop_or_continue%%" as name contains unsupported characters
Remark : None of my functions have a %% in their name.
Yep ... this what bash does to detect exported function names and this is nonnegotiable as a security feature. And this is what export -f <function> does, it prefixes any exported function with BASH_FUNC_ and also suffixes it with `%%' ... see https://unix.stackexchange.com/questions/609739/bash-exported-function-not-v...
Same kind error for environment variables :
Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "MY_LIGHT_CYAN" as value contains unsupported characters
MY_LIGHT_CYAN is defined like this MY_LIGHT_CYAN=$'\e[1;36m' or defined like this MY_LIGHT_CYAN=$'\e[1;36m'
That is an other building yard, means not bash. As I'm using systemd but not KDE not GNOME as desktop the subject of this bug seems to be misleading one. This is not a bug of systemd nor of bash. But it could be that this is a security feature to protect against malicious escape sequences in variables names as well as variable values. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c12 --- Comment #12 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dr. Werner Fink from comment #11)
(In reply to Jean-Claude Dole from comment #8)
That does not work on a fresh install of leap 15.5 nor leap 15.6 Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "BASH_FUNC_stop_or_continue%%" as name contains unsupported characters
Remark : None of my functions have a %% in their name.
Yep ... this what bash does to detect exported function names and this is nonnegotiable as a security feature.
https://en.wikipedia.org/wiki/Shellshock_(software_bug) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c13 --- Comment #13 from Dr. Werner Fink <werner@suse.com> --- (In reply to Jean-Claude Dole from comment #10)
I would like to point out that you did not answer my question: "What changes Opensuse have made after version leap 15.4"
On the other hand, in your remarks you refer to systemd. What systemd has to do with the Bash program.
Regards
Guess ... new plasma workspace version with tighten security filters in the environment handling, but this is a guess. As I'm sill using fvwm (+ lxsession + xfce4-panel) I do not face this problem. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c14 --- Comment #14 from Dirk Weber <d_werner@gmx.net> --- (In reply to Dr. Werner Fink from comment #13)
(In reply to Jean-Claude Dole from comment #10)
I would like to point out that you did not answer my question: "What changes Opensuse have made after version leap 15.4"
On the other hand, in your remarks you refer to systemd. What systemd has to do with the Bash program.
Regards
Guess ... new plasma workspace version with tighten security filters in the environment handling, but this is a guess. As I'm sill using fvwm (+ lxsession + xfce4-panel) I do not face this problem.
What has changed in Leap 15.5 is how the plasma session is started ("systemdBoot" instead of kdeinit5), see bug 1203617 comment 53. With this change together with the Shellshock counter measure setting bash functions in the profile becomes useless for interactive sessions. Or you call the functions by their Shellshock protected names... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c16 --- Comment #16 from Jean-Claude Dole <jcdole@free.fr> --- (In reply to Fabian Vogt from comment #15)
Resetting severity - this is not critical by any means.
(In reply to Dirk Weber from comment #1)
Just for information: this is basically the same problem as described by bug 1203617.
Short summary: such functions should not be defined in the profile (/etc/profile.d or ~/.profile ) but in bashrc (/etc/bash.bashrc.local, ~/.bashrc) which are intended for interactive shells.
In your case with local adaptations you can just move the definitions there.
^
IMO RESOLVED INVALID or WONTFIX.
That "%" is not a valid environment variable for "dbus-update-activation-environment --systemd" is a systemd topic: https://github.com/systemd/systemd/pull/25235
Stop that. I am not using any "%" in name. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c17 --- Comment #17 from Jean-Claude Dole <jcdole@free.fr> --- (In reply to Dr. Werner Fink from comment #11)
(In reply to Jean-Claude Dole from comment #8)
That does not work on a fresh install of leap 15.5 nor leap 15.6 Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "BASH_FUNC_stop_or_continue%%" as name contains unsupported characters
Remark : None of my functions have a %% in their name.
Yep ... this what bash does to detect exported function names and this is nonnegotiable as a security feature. And this is what
export -f <function>
does, it prefixes any exported function with BASH_FUNC_ and also suffixes it with `%%' ... see
https://unix.stackexchange.com/questions/609739/bash-exported-function-not- visible-but-variables-are
Same kind error for environment variables :
Apr 11 18:57:40 localhost.localdomain startplasma-x11[1537]: org.kde.plasma.libkworkspace: Skipping syncing of environment variable "MY_LIGHT_CYAN" as value contains unsupported characters
MY_LIGHT_CYAN is defined like this MY_LIGHT_CYAN=$'\e[1;36m' or defined like this MY_LIGHT_CYAN=$'\e[1;36m'
That is an other building yard, means not bash. As I'm using systemd but not KDE not GNOME as desktop the subject of this bug seems to be misleading one.
This is not a bug of systemd nor of bash.
But it could be that this is a security feature to protect against malicious escape sequences in variables names as well as variable values.
If I understand well, don't use bash or don't use systemd or don't use Opensuse. Or give a real solution to people that run into problems because Opensuse decides to change their mind. Just tell me how can I define an environment variable for some colors ? Just tell me how can I defined bash functions that are not available in the binaries. That should not be very difficult for Opensuse guru. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c18 --- Comment #18 from Jean-Claude Dole <jcdole@free.fr> --- Just tell me how can I define an environment variable for some colors ? Just tell me how can I defined bash functions that are not available in the binaries. For any kind of shell session ( interactive, non interactive, login or non login , .....) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c19 --- Comment #19 from Dr. Werner Fink <werner@suse.com> --- Created attachment 874405 --> https://bugzilla.suse.com/attachment.cgi?id=874405&action=edit bash.bashrc.local and profile.local Can we please all togehter calm down. First of all the change in bash for exporting shell functions (which in fact is a bash only feature) was due to a possible security attack called Shellshock. The way was to use suffixes `%%' and this is not OpenSUSE but upstream. And if systemd does not allow such variables due to their rules (also not OpenSUSE but upstream) the question is how to get bash specific environment variables system wide provided for all bash sessions. The way to go could be /etc/bash.bashrc.local and /etc/profile.local ... first fo all interactive bash session last on for all login bash sessions. The only question is why are you require variables for coloring in noninteractive bash sessions? Also you could add the shell functions to /etc/bash.bashrc.local to have those in every interactive bash session. Within bash scripts the better way is to define those function in those scripts or source the declaring bash syntax file. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #874405|text/plain |image/png mime type| | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c20 --- Comment #20 from Dr. Werner Fink <werner@suse.com> --- That is not only a openSUSE problem see https://bugzilla.redhat.com/show_bug.cgi?id=1754395 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c21 --- Comment #21 from Dr. Werner Fink <werner@suse.com> --- Maybe an executable bash script ~/.config/plasma-workspace/env/kwin_env.sh but only for a local user user is also a way (older system have ~/.kde/env/ or ~/.kde4/env/ for the location of kwin_env.sh) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c22 --- Comment #22 from Jean-Claude Dole <jcdole@free.fr> --- (In reply to Dr. Werner Fink from comment #19)
Created attachment 874405 [details] bash.bashrc.local and profile.local ... ... ...
To put it simply I decided one day to make a list of variables that I used often. With this list I was sure to always use the same name for the same object. I applied the same principle for functions that I often used; which prevented me from reinventing the wheel. On the other hand, I decided not to differentiate between different types of bash sessions; so I only have two definition files, one for variables and one for functions. To continue in simplicity I decided to make this organization available as soon as linux is powered on even before the user is logged in. I have made some test with other distributions on VBOX virtual machine. Some distro ignore my function definitions without errors if sourced in /etc/profile.d. No messages in journald concerning the infamous '%%'. It seems that systemd "clear environment" in that case. Messages sent to logger show that function definitions has been sourced without errors but does not survive. Regarding Leap 15.5, putting stuff in /etc.bashrc.local and in /etc/profile.local seems to satisfy my need. I just need to make sure that things won’t be sourced more than once. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c23 --- Comment #23 from Jean-Claude Dole <jcdole@free.fr> --- Please compare https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-ad... Table 14.1.1 Bash configuration files and Table 14.2: Bash configuration files for non-login shells There is ambiguity about the choice of '/etc/profile.d' or '/etc/profile.local' The use of '/etc/profile.d' is not prohibited for BASH. This was the source of my troubles. More complete explanations would be welcome. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c24 --- Comment #24 from Jean-Claude Dole <jcdole@free.fr> --- Thanks to everyone for your patience. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219979 https://bugzilla.suse.com/show_bug.cgi?id=1219979#c26 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|REOPENED |RESOLVED --- Comment #26 from Dr. Werner Fink <werner@suse.com> --- (In reply to Chenzi Cao from comment #25)
(In reply to Jean-Claude Dole from comment #23)
Please compare https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha- adm-shell.html Table 14.1.1 Bash configuration files and Table 14.2: Bash configuration files for non-login shells
There is ambiguity about the choice of '/etc/profile.d' or '/etc/profile.local' The use of '/etc/profile.d' is not prohibited for BASH.
I assign it to this file's maintaner to to take a look at this, thanks.
And please feel free to reassign whenever necessary, thanks.
This was the source of my troubles.
More complete explanations would be welcome.
What is the problem with /etc/profile -- Do not modify this file, otherwise your modifications may be destroyed during your next update. /etc/profile.local -- Use this file if you extend /etc/profile /etc/profile.d/ -- Contains system-wide configuration files for specific programs ~/.profile -- Insert user specific configuration for login shells here the files /etc/profile, /etc/profile.local, and ~/.profile belongs to bourne shells like the bash, ksh, mksh, (d)ash ... whereas in the directory /etc/profile.d/ not only files for various bourne shells but also e.g. the tcsh are located. Those files are provides by packages as otherwise the /etc/profile or /etc/bash.bashrc or /etc/ksh.kshrc or /etc/csh.login or /etc/csh.cshrc has to modified for every package shell based feature. rpm -qf /etc/profile.d/*.sh -- read by /etc/profile rpm -qf /etc/profile.d/*.bash -- those files will be also read by e.g. /etc/bash.bashrc rpm -qf /etc/profile.d/*.csh -- (t)csh files read by /etc/csh.login rpm -qf /etc/profile.d/*.tcsh -- tcsh files read by /etc/csh.cshrc the name /etc/profile.d/ is historically yes, but it will not be renamed. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com