A bit more information:
My PC's emergency Tumbleweed partition which shares the same home partition and is out of date openSUSE Tumbleweed  20220828-0 which I'm about to update doesn't have the menu pane on start up but the "doesn't exit into current directory" problem exists.

Which version of `mc` do you have for Leap that doesn't have problems? 4.8.27 or something else?

(In reply to Adam Majer from comment #2)
> Which version of `mc` do you have for Leap that doesn't have problems?
> 4.8.27 or something else?

I've got 4.8.27 on leap 15.4, not sure but the menu pane appearing problem is specific to the laptop and not present on my PC's Tumbleweed partition.

I've built 4.8.28 in my home repo, will try it tomorrow

mc 4.8.28 built in home:plater installed on my Leap:15.4 system performs as expected but mc 4.8.28 from home:plater on my clean Tumbleweed system has the "change into the directory that mc was started from" problem. I'm pretty sure that mc's files under /etc have been touched so they wouldn't be replaced on an mc update.

I need help, after a zypper rm -u mc on my Tumbleweed laptop and confirmation that all the packages files under etc were erased, I reinstalled from oss and no change.

On my PC's emergency Tumbleweed system which shares /home with Leap:15.4 and isn't used frequently even after replacing mc's content under /etc I still have mc functioning as expected under Leap but not exiting into it's current directory on Tumbleweed.
Any suggestions where to look next?

After removing mc and then all mc directories under ~/.cache, ~/.local and ~/.config then reinstalling mc I've got rid of the menu pane at startup problem and am now left with mc-4.8.28 exiting into it's current directory under Leap:15.4 and the same mc exiting into the directory mc started from on both the Tumbleweed laptop and the clean Tumbleweed on my pc's Tumbleweed partition.
Are you able to duplicate this behavior?

The PC's Tumbleweed shares my home partition.

(In reply to Dave Plater from comment #7)
> After removing mc and then all mc directories under ~/.cache, ~/.local and
> ~/.config then reinstalling mc I've got rid of the menu pane at startup
> problem and am now left with mc-4.8.28 exiting into it's current directory
> under Leap:15.4 and the same mc exiting into the directory mc started from
> on both the Tumbleweed laptop and the clean Tumbleweed on my pc's Tumbleweed
> partition.
> Are you able to duplicate this behavior?

For both TW and Leap, when I change the directory in mc and exit, it remains in whatever the current working directory is in the bottom of the mc window (so either left or right pane, the active one)

Now, the way that mc retains working directory in the parent shell is to define a function called mc() in the parent shell that then runs a wrapper script,

    /usr/share/mc/mc-wrapper.sh

This mc() functino is defined in,

    cat /etc/profile.d/mc.*

This means that you need to have this function defined in your shell. In bash, you can see this via,

   declare -f

If your shell cannot source this functionality or if you run /usr/bin/mc directly, the shell will not retain the working directory from mc. This "backwards" passing of CWD requires handling via extra functionality in current shell simply due to the way that fork()+exec() work in Linux.

It looks like this has something with kde's konsole. mc behaves as expected in a real tty console and in xfce's terminal. I'll see if I can downgrade konsole to Leap's version.
Everything you stated in Comment 9 checks out ok.

It's kde specific because xfce terminal has the problem in plasma5

Found the difference between PC and Tw laptop:
Leap PC:
export -f mc ; echo $?
0

And Laptop:
 export -f mc ; echo $?
bash: export: mc: not a function
1

Any idea what is likely to cause this?

Added KDE maintainer

(In reply to Dave Plater from comment #12)
> Found the difference between PC and Tw laptop:
> Leap PC:
> export -f mc ; echo $?
> 0
> 
> And Laptop:
>  export -f mc ; echo $?
> bash: export: mc: not a function
> 1
> 
> Any idea what is likely to cause this?


> help export
export: export [-fn] [name[=value] ...] or export -p
    Set export attribute for shell variables.
    
    Marks each NAME for automatic export to the environment of subsequently
    executed commands.  If VALUE is supplied, assign VALUE before exporting.
    
    Options:
      -f        refer to shell functions

'mc' is a program, not a function. I'm not sure to understand why this would be an issue.

For the initial report (mc exiting in the directory it was started from), the behaviour is consistent with what I've seen since many years.

(In reply to Christophe Giboudeaux from comment #14)
> (In reply to Dave Plater from comment #12)
> > Found the difference between PC and Tw laptop:
> > Leap PC:
> > export -f mc ; echo $?
> > 0
> > 
> > And Laptop:
> >  export -f mc ; echo $?
> > bash: export: mc: not a function
> > 1
> > 
> > Any idea what is likely to cause this?
> 
> 
> > help export
> export: export [-fn] [name[=value] ...] or export -p
>     Set export attribute for shell variables.
>     
>     Marks each NAME for automatic export to the environment of subsequently
>     executed commands.  If VALUE is supplied, assign VALUE before exporting.
>     
>     Options:
>       -f        refer to shell functions
> 
> 'mc' is a program, not a function. I'm not sure to understand why this would
> be an issue.
> 
> For the initial report (mc exiting in the directory it was started from),
> the behaviour is consistent with what I've seen since many years.
Read Comment 9 where  Adam Majer says that both Tumbleweed's and Leap's mc exits into the directory that it's currently in. I've been using mc to search and exit into directories.
This is the normal behavior of mc and works in xfce and icewm. Also works like that in Leap:15.4's plasma5 but only in Tumbleweed's plasma5 it exits into the directory that it started in. The only difference between the other GUIs and Tumbleweed's plasma5 is that this command fails:
 export -f mc ; echo $?
bash: export: mc: not a function
1
This is apparently part of mc's process of exiting to it's current directory.
What is different between the GUIs that could cause this?

The best advice I can give is:

echo "alias mc='source /usr/share/mc/mc-wrapper.sh'" >> ~/.profile

(In reply to Christophe Giboudeaux from comment #16)
> The best advice I can give is:
> 
> echo "alias mc='source /usr/share/mc/mc-wrapper.sh'" >> ~/.profile

sorry, this was meant to be:

echo "alias mc='source /usr/share/mc/mc-wrapper.sh'" >> ~/.bashrc

(In reply to Dave Plater from comment #15)
> This is apparently part of mc's process of exiting to it's current directory.
> What is different between the GUIs that could cause this?

Last comment to answer this. What you see is the difference between a interactive login shell (which reads /etc/profile) and an interactive non-login shell (which only reads your shell configuration file)

This can be demonstrated easily, in konsole, run `ssh localhost`, this will read the profile files and mc will behave the way you want.

(In reply to Christophe Giboudeaux from comment #18)
> (In reply to Dave Plater from comment #15)
> > This is apparently part of mc's process of exiting to it's current directory.
> > What is different between the GUIs that could cause this?
> 
> Last comment to answer this. What you see is the difference between a
> interactive login shell (which reads /etc/profile) and an interactive
> non-login shell (which only reads your shell configuration file)
> 
> This can be demonstrated easily, in konsole, run `ssh localhost`, this will
> read the profile files and mc will behave the way you want.

"echo "alias mc='source /usr/share/mc/mc-wrapper.sh'" >> ~/.bashrc" works, the next question is - why is this needed in Tumbleweed plasma5 
 Leap:15.4 doesn't have the line "alias mc='source /usr/share/mc/mc-wrapper.sh'" >> ~/.bashrc in ~/.profile seeing the alias command prompted me to check my bash.bashrc.local

To answer this, I have a bash.bashrc.local on all my computers with various alias statements and export EDITOR=mcedit .They are identical across all three systems. I moved the laptop one to bash.bashrc.local.bu and logged out and in and mc behaved as expected. I copied over Leap's bash.bashrc.local and logged out and in. Still mc behaves as expected. Moved bash.bashrc.local to bash.bashrc.local.leap and bash.bashrc.local.bu back to bash.bashrc.local and still mc behaves as expected. I didn't check permissions or owners but the Leap copy ended up with user permissions whereas the original has root ownership. I've deleted the leap bash.bashrc.local and rebooted for good measure and still I can't reproduce this bug. Next step is to boot into this PC's Tumbleweed and maybe I can find out what went right.

From my pov, the issue is in Leap if it reads /et/profile* for non-login shells.

As the behaviour is the same on Tumbleweed if mc is executed in xterm, I suggest looking at the differences in the aaa_base packages.

I'm lost:
1) 100% confirmed that in Tumbleweed only in plasma5 mc doesn't exit to it's current directory, whether in konsole or xterm. It exits into the directory it was started in.

2) Under any other window managers I've tested icewm and xfce in Tumbleweed and mc exits into the directory that is the current working directory and not into the directory it was started in.

3)If /usr/share/mc/mc-wrapper.sh is run in the current shell then mc behaves 
ie. "source /usr/share/mc/mc-wrapper.sh" so creating an alias for mc that points to that command causes mc to work correctly no matter which environment.

4)Leap:15.4 doesn't have this problem at all and has no alias.

I can put the alias into my bash.bashrc.local and never have the problem again.

Is this reproducible on another tumbleweed plasma5 system or do I need to do a complete reinstall of my PC's emergency Tumbleweed partition?

(In reply to Dave Plater from comment #21)
> 4)Leap:15.4 doesn't have this problem at all and has no alias.

I'm using SLED 15.3 still and I "would have this problem" locally, in gnome-terminal or xterm.

The issue is around this "login" vs. "non-login" shells. And there is no centralized way of adding these configs to non-login shells except to adjust /etc/bash.bashrc

I wonder if it makes sense to modify this file for everyone for interactive shells or we are just seeing a one-off. As far as I know, no one else has complained about this so far.

Also, you do not have to exit mc to go into full screen mode of its shell. Just press Ctrl-O and then again to get back to mc. Would this be a good workaround for this "feature"?

I would put the alias in my bash.bashrc.local as a workaround. I normally copy that to any system I have. Meanwhile I'm building Leap's bash for Tumbleweed to see if the problem comes from a bash update.

I've downgraded my laptop to Leap:15.4 and mc is usable again. Same home and /etc configuraton as before. When I have spare time I'll look into this bug further but it seems that either nobody uses mc like I do anymore or it's was just my system.

possibly a clue to the reason for this behavior. On 15.4's mc, if I use sudo mc then on exit I return to the original directory I started from. Can it be that mc in Tumbleweed is somehow changing the user when opened and changing back when closed

On update to Leap:15.5 rc my laptop now has this problem

:~> mc --version
GNU Midnight Commander 4.8.27
Built with GLib 2.70.5
Built with S-Lang 2.3.1a with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, smbfs
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

I am observing this too on Leap 15.5.

Maybe a hint?
In konsole:

$ type mc
mc is hashed (/usr/bin/mc)


in an ssh session to the same system and the same user or on a console terminal (e.g. Alt-F1):
$ type mc
mc is a function
mc () 
{ 
    . /usr/share/mc/mc-wrapper.sh
}

And I think the definition of this function comes from
/etc/profile.d/mc.sh -> /usr/share/mc/mc.sh

which come both from the mc package:
$ rpm -qf /etc/profile.d/mc.sh
mc-4.8.27-bp155.2.13.x86_64
$ rpm -qf /usr/share/mc/mc.sh
mc-4.8.27-bp155.2.13.x86_64

This appears to be KDE specific. I tried different versions of mc in fact the one I have on my Leap:15.4 system is 4.8.28 and 4.8.27 on my Leap:15.5 system.
The bug only appears to occur in the KDE desktop and not in icewm or xfce even running konsole.

(In reply to Dave Plater from comment #29)
> This appears to be KDE specific. I tried different versions of mc in fact
> the one I have on my Leap:15.4 system is 4.8.28 and 4.8.27 on my Leap:15.5
> system.
> The bug only appears to occur in the KDE desktop and not in icewm or xfce
> even running konsole.

I confirm it is plasma session specific.

konsole running in an icewm session (tumbleweed):

$ type mc
mc is a function
mc () 
{ 
    . /usr/share/mc/mc-wrapper.sh
}

The current directory of the active mc panel at exit is kept.


Same machine, same user, but session type plasma-X11:
$ type mc
mc is hashed (/usr/bin/mc)

exit of mc takes one back to the CWD where it was started and this is new for me in Leap 15.5, Leap 15.4 did not behave like this.


For me it seems the difference might be how user sessions are started by the DE and the influence this has on reading the scriptlets in
/etc/profile.d/
or not.

The upgrade from Leap 15.4 to Leap 15.5 did not update the packages aaa_base (comment 20) and bash (comment 23) - they are still the same as in Leap 15.4:

$ lsb-release  -r
Release:        15.5

$ rpm -q --last aaa_base
aaa_base-84.87+git20180409.04c9dae-150300.10.3.1.x86_64 Do 22 Dez 2022 17:10:02 CET

$ rpm -q --last bash
bash-4.4-150400.25.22.x86_64                  Fr 03 Jun 2022 17:08:53 CEST




My current workaround is:

$ tail -3 ~/.bashrc 

# bnc#1203617 workaround plasma
[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh

I just stumbled over this line

org.kde.plasma.libkworkspace: Skipping syncing of environment variable  "BASH_FUNC_mc%%" as name contains unsupported characters

in ~/.local/share/sddm/wayland-session.log

and online search for this output found 
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/569


But I have no idea where this %% in the variable name comes from.

(In reply to Dirk Weber from comment #32)
> I just stumbled over this line
> 
> org.kde.plasma.libkworkspace: Skipping syncing of environment variable 
> "BASH_FUNC_mc%%" as name contains unsupported characters
> 
> in ~/.local/share/sddm/wayland-session.log
> 
> and online search for this output found 
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/569
> 
> 
> But I have no idea where this %% in the variable name comes from.

Now I think we are getting warmer, I'll look into whether that commit is not present in 15.4 but is in 15.5 over the next few days.
Clone git and use "git gui" to track the commit against tags
a % in that context is to be replaced by a variable

I found out where the 
"BASH_FUNC_foobar%%" comes from:

according to this article 
https://unix.stackexchange.com/questions/233091/bash-functions-in-shell-variables
it is a Shellshock counter measure in bash.


So it seems the combination of this Shellshock counter measure in bash and the filtering of special characters in org.kde.plasma.libkworkspace disables the possibility to have shell functions defined in the profile and use them in the shells started within plasma sessions.

If the filtering of %% is really necessary in org.kde.plasma.libkworkspace then probably these function definitions have to be moved from profile.d to bashrc.

Maybe org.kde.plasma.libkworkspace can allow names of the format
"BASH_FUNC_[isPosixName]%%"

(In reply to Dave Plater from comment #33)
> (In reply to Dirk Weber from comment #32)
> > I just stumbled over this line
> > 
> > org.kde.plasma.libkworkspace: Skipping syncing of environment variable 
> > "BASH_FUNC_mc%%" as name contains unsupported characters
> > 
> > in ~/.local/share/sddm/wayland-session.log
> > 
> > and online search for this output found 
> > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/569
> > 
> > 
> > But I have no idea where this %% in the variable name comes from.
> 
> Now I think we are getting warmer, I'll look into whether that commit is not
> present in 15.4 but is in 15.5 over the next few days.
> Clone git and use "git gui" to track the commit against tags
> a % in that context is to be replaced by a variable

sorry, I just found this log line also in Leap 15.4's 
~/.local/share/sddm/wayland-session.log
but the variable still gets defined.

Maybe it was only a log output in plasma of Leap 15.4 but it was actually not skipped, and in plasma of Leap 15.5 it is really skipped.

The commit is somewhere between:
8ee62c09d710ec5e151595a3a59f9f41d4e76b83 5.24.4 2022-03-29 Leap:15.4
and
bd20a2fa3467019291e2dfc02f364df6f4ea4cfb 5.27.4 2023-04-04 Leap:15.5

This bug turns mc from a useful command line tool to just another file manager.

I did some more research on the issue.

I found discussions about setting the environment 
also in systemd development:
https://github.com/systemd/systemd/issues/14878
https://github.com/systemd/systemd/pull/17188

With this information I tend to conclude that 
/etc/profile.d/
is not the right place to define shell functions
which are only needed in interactive shell sessions.

Maybe the definition of the mc function should be moved to
/etc/skel/.bashrc

Of course for packages it is convenient to just drop 
files int /etc/profile.d/ and something similar does not
exist for 
/etc/bash.bashrc
(/etc/bash.bashrc.local is for the local admin to maintain).

But I think for users of mc it is also not a big problem
to modify their ~/.bashrc or /etc/bash.bashrc.local
by adding 

[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh || true

in order to restore the functionality to stay in the current directory of the active mc panel upon exit as it was.


It would make such analysis much easier if systemd would also write a log message if it is "Ignoring invalid environment assignment" and not only with level debug.

(In reply to Dirk Weber from comment #37)
> Of course for packages it is convenient to just drop 
> files int /etc/profile.d/ and something similar does not
> exist for 
> /etc/bash.bashrc
> (/etc/bash.bashrc.local is for the local admin to maintain).
> 
> But I think for users of mc it is also not a big problem
> to modify their ~/.bashrc or /etc/bash.bashrc.local
> by adding 
> 
> [ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh || true
> 
> in order to restore the functionality to stay in the current directory of
> the active mc panel upon exit as it was.
> 

This is a solution or a workaround so far, I inserted:
 [ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh || true
into my /etc/bash.bashrc.local and it solved the problem, mc exits into the directory that it is in before exit.
All that's needed is the correct place for the statement to be placed in.

I've opened:
https://bugs.kde.org/show_bug.cgi?id=470983

*** Bug 1212342 has been marked as a duplicate of this bug. ***

Suggestions for possible solutions I can think of:

1) kde reverts to the old way of starting sessions - quite unlikely

2) systemd stops or changes the filtering of profile settings - quite unlikely

3) bash settings (functions) are read differently, not as "profile" (for login sessions)
but as "bashrc" for interactive sessions. 
This would probably involve modifications in the aaa_base package
to split the loading of profile and bashrc files.
e.g. 
/etc/bash.bashrc
could (also) read /etc/profile.d
which could be bad from performance point of view or could
result in overwriting settings or in a loop.

Or a new directory like
/etc/bash.bashrc.d/
could be created which then is read by the interactive shell (similar to ~/.bashrc)
and the mc package would need to move /etc/profile.d/mc.sh to this directory.

No intervention in bash or mc should be necessary to fix this bug. It is a KDE problem and KDE should be fixed.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/569
This commit is present in both plasma5-workspace 5.27.4.1 from leap 15.5 and in plasma5-workspace 5.24.4 from 15.4 and completely removing it makes no difference to this bug

(In reply to Dave Plater from comment #43)
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/569
> This commit is present in both plasma5-workspace 5.27.4.1 from leap 15.5 and
> in plasma5-workspace 5.24.4 from 15.4 and completely removing it makes no
> difference to this bug

I already wrote in comment 35 that the line
org.kde.plasma.libkworkspace: Skipping syncing of environment variable 
"BASH_FUNC_mc%%" as name contains unsupported characters
also appears in Leap 15.4.

Therefore it is unlikely that this code in kde is the cause.

It is more likely related to the change how plasma sessions are started in Leap 15.5 (and Tumbleweed) via systemd and the related handling of environment settings by systemd as discussed in 
https://github.com/systemd/systemd/issues/14878
https://github.com/systemd/systemd/pull/17188

Therefore my suggestions in comment 45.

And I did *not* mention that bash should be changed. 
bash can distinguish between login shells and interactive shells.

It only needs to be given the suitable environment which is handled by aaa_base.

(In reply to Dirk Weber from comment #44)
> (In reply to Dave Plater from comment #43)
> > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/569
> > This commit is present in both plasma5-workspace 5.27.4.1 from leap 15.5 and
> > in plasma5-workspace 5.24.4 from 15.4 and completely removing it makes no
> > difference to this bug
> 
> I already wrote in comment 35 that the line
> org.kde.plasma.libkworkspace: Skipping syncing of environment variable 
> "BASH_FUNC_mc%%" as name contains unsupported characters
> also appears in Leap 15.4.
> 
> Therefore it is unlikely that this code in kde is the cause.
> 
> It is more likely related to the change how plasma sessions are started in
> Leap 15.5 (and Tumbleweed) via systemd 
this was an interpretation from bug 1211977, comment 1, but on closer look this is about autostart files, so maybe not related to the setting up of the whole user environment.

> ...and the related handling of
> environment settings by systemd as discussed in 
> https://github.com/systemd/systemd/issues/14878
> https://github.com/systemd/systemd/pull/17188
> 
> Therefore my suggestions in comment 45.
that should be comment 41.

I tried to get the debug output from systemd about the invalid environment assignment but could not get it.

I don't think this is related to KDE. I can reproduce this in GNOME as well on SLED 15.4. Even when I set to run as login shell in the GNOME terminal settings.

(In reply to Adam Majer from comment #46)
> I don't think this is related to KDE. I can reproduce this in GNOME as well
> on SLED 15.4. Even when I set to run as login shell in the GNOME terminal
> settings.

Does inserting "[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh || true" into /etc/bash.bashrc.local fix the behavior in GNOME?

(In reply to Dave Plater from comment #47)
> (In reply to Adam Majer from comment #46)
> > I don't think this is related to KDE. I can reproduce this in GNOME as well
> > on SLED 15.4. Even when I set to run as login shell in the GNOME terminal
> > settings.
> 
> Does inserting "[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh ||
> true" into /etc/bash.bashrc.local fix the behavior in GNOME?

Of course this would fix the problem. The problem is that /etc/profile.d/mc.sh is not getting included. This wrapper is necessary to change the CWD (current working directory) of the parent (bash, in this case) to the the one of the child (mc)

> cat /proc/$$/cmdline 
-bash

This should indicate a login shell, but yet, mc is not read into it

> declare -f mc

> . /etc/profile.d/mc.sh
> declare -f mc
mc () 
{ 
    . /usr/share/mc/mc-wrapper.sh
}

mc must be defined as a shell function. If you run it as /usr/bin/mc, that will *never* exit to the directory it sets internally since there is no mechanism for changing the CWD of the parent process.

You can see what this magic function does by looking in the wrapper itself,

> cat /usr/share/mc/mc-wrapper.sh
MC_USER=`whoami`
MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"
/usr/bin/mc -P "$MC_PWD_FILE" "$@"

if test -r "$MC_PWD_FILE"; then
	MC_PWD="`cat "$MC_PWD_FILE"`"
	if test -n "$MC_PWD" && test "$MC_PWD" != "$PWD" && test -d "$MC_PWD"; then
		cd "$MC_PWD"
	fi
	unset MC_PWD
fi

rm -f "$MC_PWD_FILE"
unset MC_PWD_FILE
unset MC_USER

Basically, a temporary file is used by /usr/bin/mc to write the CWD of midnight commander at exit. The shell function then reads this file and sets its own CWD to this directory.


So the question now is, why is /etc/profile.d/mc.sh not sourced.

(In reply to Adam Majer from comment #48)
> (In reply to Dave Plater from comment #47)
> > (In reply to Adam Majer from comment #46)
> > > I don't think this is related to KDE. I can reproduce this in GNOME as well
> > > on SLED 15.4. Even when I set to run as login shell in the GNOME terminal
> > > settings.
> > 
> 
> So the question now is, why is /etc/profile.d/mc.sh not sourced.
Maybe the problem is different on SLED 15.4, but on Leap 15.5 (I checked several systems with it) this behavior has changed with the upgrade from Leap 15.4 to Leap 15.5. Preserving the directory in KDE sessions worked with 15.4 and does no longer work with 15.5 by default.


/etc/profile.d/mc.sh is definitely sourced upon starting the session, this is shown by the log output (comment 32)

org.kde.plasma.libkworkspace: Skipping syncing of environment variable  "BASH_FUNC_mc%%" as name contains unsupported characters

in ~/.local/share/sddm/wayland-session.log

(or if X11 is used in the syslog).

It can also be proved by an strace on sddm while logging in to the plasma session like

# strace -fp $(pidof sddm) -o  login_plasma_15x.txt -s 128


Leap 15.5:

grep -E 'BASH_FU|kdeinit|mc.sh' login_plasma_155.txt
8081  faccessat(AT_FDCWD, "/etc/profile.d/mc.sh", R_OK) = 0
8081  stat("/etc/profile.d/mc.sh", {st_mode=S_IFREG|0755, st_size=200, ...}) = 0
8081  openat(AT_FDCWD, "/etc/profile.d/mc.sh", O_RDONLY) = 3
8081  write(2, "org.kde.plasma.libkworkspace: Skipping syncing of environment variable  \"BASH_FUNC_mc%%\" as name contains unsupported characters"..., 129 <unfinished ...>
8081  write(2, "org.kde.plasma.libkworkspace: Skipping syncing of environment variable  \"BASH_FUNC_mc%%\" as name contains unsupported characters"..., 129 <unfinished ...>


comparing with Leap 15.4 shows that Leap 15.4 also produces the log messages 
"Skipping syncing of environment variable  \"BASH_FUNC_mc%%\" as name contains unsupported characters\n" (comment 35)
but afterwards start_kdeinit is reading the profile and setting up the BASH_FUNC_mc%% so that it is available afterwards in the started session:

Leap 15.4:

grep -E 'BASH_FU|kdeinit' login_plasma_154.txt
2894  write(2, "Skipping syncing of environment variable  \"BASH_FUNC_mc%%\" as name contains unsupported characters\n", 99 <unfinished ...>
2894  write(2, "Skipping syncing of environment variable  \"BASH_FUNC_mc%%\" as name contains unsupported characters\n", 99 <unfinished ...>
2938  execve("/usr/lib64/libexec/kf5/start_kdeinit_wrapper", ["/usr/lib64/libexec/kf5/start_kdeinit_wrapper"], 0x11d4890 /* 83 vars */ <unfinished ...>
2938  execve("/usr/lib64/libexec/kf5/start_kdeinit", ["/usr/lib64/libexec/kf5/start_kdeinit"], 0x7ffea96aa078 /* 83 vars */ <unfinished ...>
2939  write(4, "BASH_FUNC_mc%%=() {  . /usr/share/mc/mc-wrapper.sh\n}", 52 <unfinished ...>
2938  read(0, "BASH_FUNC_mc%%=() {  . /usr/share/mc/mc-wrapper.sh\n}", 52) = 52
...



So for KDE I would say there is really a difference how the session is started between 15.4 and 15.5 which causes this changed behavior.

No idea if this is related, but in 15.5, in running Konsole3's menu selection "New Midnight Commander" in a Plasma5 login session started from KDM3, Ctrl-O produces error: "common.c: unimplemented subshell type 1", whether or not /etc/bash.bashrc.local contains "[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh || true".

(In reply to Felix Miata from comment #50)
> No idea if this is related, but in 15.5, in running Konsole3's menu
> selection "New Midnight Commander" in a Plasma5 login session started from
> KDM3, Ctrl-O produces error: "common.c: unimplemented subshell type 1",
> whether or not /etc/bash.bashrc.local contains "[ $(type -t mc) = "file" ]
> && . /etc/profile.d/mc.sh || true".

That is a completely different issue - it's about a subshell. Please create a new bug report for this.

I asked the mc developers about this issue (the first reply insisted that exiting to the starting directory is normal) and I now understand fully what the issue is - kde make every script executed in a virtual console run in a sandbox.

The most important element in:
 "[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh"
which I've been missing is "." which help . in a bash shell says is:
"Execute commands from a file in the current shell"

Starting mc like this ". /etc/profile.d/mc.sh && mc" lets mc to exit to it's CWD.

To prove this I created a script:
#! /usr/bin/bash

  dirc()
  {
  pushd ../../
  }
  
  dirc

and when executing the script although the output of pushd is clear it exits to the directory it was started in. Prepending "." changes directory to the two upper levels as if "pushd ../../" is executed from the command line.

Perhaps a KDE expert can shed more light on this.

As already very much suspected the issue seems related to how the plasma session is started in Leap 15.5 using the "systemdBoot" instead of kdeinit5.

Bug 1213156, comment 23 explains how to deactivate the start of the plasma session by systemd, and by applying this configuration and relogin to the plasma session the setting of the mc function in the 
/etc/profile.d/mc.sh
becomes available in the plasma session (e.g. konsole) like it was in Leap 15.4 and this restores the mc functionality to stay in the last directory upon quitting mc.

So this is another workaround in addition to the one from comment 37.
As discussed in bug 1213156 starting the plasma session like this in plasma 5.27 could be less tested.

The Xsession resp. wayland-session scripts run during login source /etc/profile
to set up the environment for the graphical environment. This sets variables like
"$BASH_FUNC_mc%%" but also "$PROFILEREAD". Plasma's components are started through
systemd user services and dbus activation. To set up the environment for those,
variables of the session process are sent to dbus and systemd. However, there
are some exceptions! % is not a valid variable name in the systemd context so
this is not actually sent. Other variables like $PROFILEREAD are.

konsole is eventually started and the shell inherits the environment from systemd,
meaning without $BASH_FUNC_mc%%.

Even if the shell was invoked as login shell or /etc/profile sourced manually,
it sees that $PROFILEREAD is already set and doesn't do anything.

The root cause and fix should be relatively simple: /etc/profile is only meant
for "normal" environment variables. Bash specific stuff like this mc() function
must be in bashrc instead.

(In reply to Dave Plater from comment #52)
> I asked the mc developers about this issue (the first reply insisted that
> exiting to the starting directory is normal) and I now understand fully what
> the issue is - kde make every script executed in a virtual console run in a
> sandbox.

That's not really the case, there's no sandboxing going on. It's just
independent shell processes.

> The most important element in:
>  "[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh"
> which I've been missing is "." which help . in a bash shell says is:
> "Execute commands from a file in the current shell"
> 
> Starting mc like this ". /etc/profile.d/mc.sh && mc" lets mc to exit to it's
> CWD.
> 
> To prove this I created a script:
> #! /usr/bin/bash
> 
>   dirc()
>   {
>   pushd ../../
>   }
>   
>   dirc
> 
> and when executing the script although the output of pushd is clear it exits
> to the directory it was started in. Prepending "." changes directory to the
> two upper levels as if "pushd ../../" is executed from the command line.
> 
> Perhaps a KDE expert can shed more light on this.

That's unrelated to KDE, it's just a shell thing:

If you execute a script, it starts a new shell. Changing directory in there
has no impact on the parent (interactive) shell. If instead of executing you
*source* this script (that's what "." is) it is like you typed in the commands
into the shell itself.

(In reply to Fabian Vogt from comment #54)
> 
> The root cause and fix should be relatively simple: /etc/profile is only
> meant
> for "normal" environment variables. Bash specific stuff like this mc()
> function
> must be in bashrc instead.

In /etc/profile files from /etc/profile.d are sourced.

A similar mechanism is missing in Leap/openSUSE's /etc/bash.bashrc.

I assume that is the main reason why 
/etc/profile.d/mc.csh
/etc/profile.d/mc.sh
exist.
And up to now (plasma session started by systemdBoot) this worked and was good enough.

Refining my suggestion 3) from comment 41: probably a new directory 
/etc/bashrc.d
should be created which is sourced by /etc/bash.bashrc (change in the aaa_base package).
/etc/profile.d is part of the filesystem package.

Into this new directory the link 
/etc/bashrc.d/mc.sh -> /usr/share/mc/mc.sh
is created (change in the mc package - the link could be created conditionally in the post section of the rpm if the directory exists, and removed in the postun section in the case of final uninstall).

(In reply to Fabian Vogt from comment #54)
> The root cause and fix should be relatively simple: /etc/profile is only
> meant
> for "normal" environment variables. Bash specific stuff like this mc()
> function
> must be in bashrc instead.
> 
> (In reply to Dave Plater from comment #52)
> > I asked the mc developers about this issue (the first reply insisted that
> > exiting to the starting directory is normal) and I now understand fully what
> > the issue is - kde make every script executed in a virtual console run in a
> > sandbox.
> 
> That's not really the case, there's no sandboxing going on. It's just
> independent shell processes.
> 
Sorry independently would have been a better word

> > The most important element in:
> >  "[ $(type -t mc) = "file" ] && . /etc/profile.d/mc.sh"
> > which I've been missing is "." which help . in a bash shell says is:
> > "Execute commands from a file in the current shell"
> > 
> > Starting mc like this ". /etc/profile.d/mc.sh && mc" lets mc to exit to it's
> > CWD.
> > 
> > To prove this I created a script:
> > #! /usr/bin/bash
> > 
> >   dirc()
> >   {
> >   pushd ../../
> >   }
> >   
> >   dirc
> > 
> > and when executing the script although the output of pushd is clear it exits
> > to the directory it was started in. Prepending "." changes directory to the
> > two upper levels as if "pushd ../../" is executed from the command line.
> > 
> > Perhaps a KDE expert can shed more light on this.
> 
> That's unrelated to KDE, it's just a shell thing:
> 
> If you execute a script, it starts a new shell. Changing directory in there
> has no impact on the parent (interactive) shell. If instead of executing you
> *source* this script (that's what "." is) it is like you typed in the
> commands
> into the shell itself.

Sorry once again what I meant was that the shell no longer behaves the same in Tumbleweed (which is where I first found this bug) and Leap:15.5 as it behaved in previous versions. It doesn't exist in icewm and xfce4, I haven't tested gnome so I assumed from this that it is a kde problem. This bug also affects my ability to change directories in bash scripts and still be in that directory on exit eg. a script to find a directory and change to it.

The fix in Bug 1213156 also solves this bug

Disabling kde's use of systemd fixes this bug.

*** This bug has been marked as a duplicate of bug 1213156 ***

It is unrelated to xdg-autostart-generator.

(In reply to Fabian Vogt from comment #59)
> It is unrelated to xdg-autostart-generator.

Then how do you explain this bug being fixed with:
"> We can test it without recompile by creating: ~/.config/startkderc
> and write the following to the file.
> 
> ```
> [General]
> systemdBoot=false
"
Or is this black magic?

I've never seen you replying to any of my comments in Bug 1213156 either.

*** This bug has been marked as a duplicate of bug 1213156 ***

Since 2023-08-06 10:50:58 UTC I have applied the fix and made sure that everything is back to normal I even commented:
 https://bugzilla.suse.com/show_bug.cgi?id=1213156#c25 and was not told in that bug which you are very active in.

(In reply to Dave Plater from comment #60)
> (In reply to Fabian Vogt from comment #59)
> > It is unrelated to xdg-autostart-generator.
> 
> Then how do you explain this bug being fixed with:
> "> We can test it without recompile by creating: ~/.config/startkderc
> > and write the following to the file.
> > 
> > ```
> > [General]
> > systemdBoot=false
> "
> Or is this black magic?

Bug 1213156 is solely about systmemd-xdg-autostart-generator not working with certain .desktop files.

This bug is about terminals started through systemd services not having BASH_FUNC_mc%% set.

Reassigning to Fabian and removing myself from this bug as a fix is on it's way to 15.5

BTW this bug is about kde and global bash shells

This bug is fixed with:
~/.config/startkderc
> > and write the following to the file.
> > 
> > ```
> > [General]
> > systemdBoot=false

(In reply to Dave Plater from comment #63)
> Reassigning to Fabian and removing myself from this bug as a fix is on it's
> way to 15.5

The fix it to have the mc integration in bashrc, not /etc/profile.

Is there a SR already?

(In reply to Dave Plater from comment #65)
> > > [General]
> > > systemdBoot=false

WFM in Slowroll :)

Created attachment 872641 [details]
Patch for /etc/bash.bashrc Leap 15.5

This patch is for /etc/bash.bashrc as it is currently in openSUSE Leap 15.5 (and 15.6, Tumbleweed is slightly different):
aaa_base-84.87+git20180409.04c9dae-150300.10.9.1.x86_64

The patch adds sourcing of 
/etc/profile.d/mc.sh 
or 
/usr/share/mc/mc.sh 
if they exist in order to set up the function mc also for plasma users in their bash environment.

The patch adds this in similar way as it is already done for sourcing
/etc/profile.d/vte.sh

Changing to Basesystem as /etc/bash.bashrc and aaa_base belong there.

Sure adding yet another dirty hack like that won't add much to the equation. Maybe we can separate profile.d scriptlets from bashrc stuff in a more more generic way while we are at it?

AFAICT *.sh is sourced by profile, maybe make bashrc source *.bash?

I'll hand this over to Werner as he is the expert for shell magic.

(In reply to Dirk Weber from comment #68)
> Created attachment 872641 [details]
> Patch for /etc/bash.bashrc Leap 15.5
> 
> This patch is for /etc/bash.bashrc as it is currently in openSUSE Leap 15.5
> (and 15.6, Tumbleweed is slightly different):
> aaa_base-84.87+git20180409.04c9dae-150300.10.9.1.x86_64
> 
> The patch adds sourcing of 
> /etc/profile.d/mc.sh 
> or 
> /usr/share/mc/mc.sh 
> if they exist in order to set up the function mc also for plasma users in
> their bash environment.
> 
> The patch adds this in similar way as it is already done for sourcing
> /etc/profile.d/vte.sh

Why are you patching /etc/bash.bashrc instead of /etc/bash.profile ... does
/etc/profile.d/mc.sh and/or /usr/share/mc/mc.sh include shell functions
or only environment variables?

Also is there a (t)csh flavour of this?

Found /usr/share/mc/mc-wrapper.csh ... but

 if ($?TMPDIR) then
        setenv MC_PWD_FILE $TMPDIR/mc-$MC_USER/mc.pwd.$$
 else
        setenv MC_PWD_FILE /tmp/mc-$MC_USER/mc.pwd.$$
 endif

even with $MC_USER the use of the pid of the current shell
instead of mktemp(1) looks fishy ;)

The same strange thing for /usr/share/mc/mc-wrapper.sh

 MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"

... is this required?

(In reply to Dr. Werner Fink from comment #73)
> Found /usr/share/mc/mc-wrapper.csh ... but
> 
>  if ($?TMPDIR) then
>         setenv MC_PWD_FILE $TMPDIR/mc-$MC_USER/mc.pwd.$$
>  else
>         setenv MC_PWD_FILE /tmp/mc-$MC_USER/mc.pwd.$$
>  endif
> 
> even with $MC_USER the use of the pid of the current shell
> instead of mktemp(1) looks fishy ;)
> 
> The same strange thing for /usr/share/mc/mc-wrapper.sh
> 
>  MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"
> 
> ... is this required?

See Bug 1221228

It's required to cd directory of parent shell to the current session in mc. This bug is about this hack not working because the function is not defined.

Created attachment 873396 [details]
mc.patch

Both tcsh and bash