Bug 1219979

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.

These functions must be available for any bash script interactive shells or not.
So they must be sourced at least from /etc/profile.d or /etc/profile. I did not see any other place.

I use these function  that way for years, and it fails now from leap 15.

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.

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?

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.

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

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

(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'

(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

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

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

(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)

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

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

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

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

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

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 , .....)

Created attachment 874405 [details]
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.

That is not only a openSUSE problem see https://bugzilla.redhat.com/show_bug.cgi?id=1754395

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)

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

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.

This was the source of my troubles. 

More complete explanations would be welcome.

Thanks to everyone for your patience.

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

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