[SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

newsboost · 2022-08-23 08:38:41

Hi all,

I've used Midnight commander for years and it's wonderful for e.g. sync'ing two directories. I have two laptops, both Arch Linux, very similar setup, even same ~/.zshrc files - but one is 3 years older than the other. Software-wise, the difference should be small. I just don't get it.... Midnight commander (mc) has a subshell-feature, i.e. when I hit CTRL+O it should give me access to a terminal where I can type terminal commands). But that subshell part works only on one of laptops as a normal user... On the other it only works if I'm root. By "it doesn't work" I mean: I get a black screen that resembles the terminal-look, but as soon as a press a key and begin to type something it goes back to the usual blue dual-split mode and "exits" the terminal-mode (if it was ever in it, it's like hitting CTRL+O again except I just typed a single character in the "subshell"). I use zsh and would prefer to keep it that way. On both machines, I have this alias:

mc='SHELL=/usr/bin/bash mc'

I left a comment to myself about the reason for having this and it's made that way so I can use "nnn" inside the subterminal mode (https://github.com/jarun/nnn). Does anyone have any ideas? I'm lost and don't understand it...

UPDATE: hmm... this sounds suspiciously a lot like here, but that is on a mac: http://midnight-commander.org/ticket/4356 & here: https://midnight-commander.org/ticket/3121 - hmm, I guess it's a zsh-problem and there's no easy fix then, except I could maybe try to build from sources... hmm...

Last edited by newsboost (2022-08-24 18:48:32)

seth · 2022-08-23 11:43:58

Does it work if you move your ~/.zshrc away?
(If it wasn't user-bound, I'd almost say the key is demi-bouncing and the next input triggers the second ctrl+o to be finished)

newsboost · 2022-08-23 14:04:55

seth wrote:

Does it work if you move your ~/.zshrc away?
(If it wasn't user-bound, I'd almost say the key is demi-bouncing and the next input triggers the second ctrl+o to be finished)

Ooh, that's a terrific idea, why didn't I think of that myself? Yes, it works! So I did a "bisect" and commented out lines until I found the culprit (at least on my system). For some weird reason, the culprit is the small program "neofetch". Explanation: my .zshrc (as well as my .bashrc, which I never use) sources another file:

#Source some shared stuff - both for bash and zsh:
local sourceFile=~/bashZsh_source_shell.sh
[[ -f "$sourceFile" ]] && source "$sourceFile"

... and in the end of that file ("sourceFile" above) I had a line "neofetch", so some system info is shown up as I open up a new terminal window. But it's reaaaly weird. I then tried leaving out this "neofetch" line so things would work, but manually on the terminal, I did:

echo $$
neofetch
echo $$

And the result are two identical numbers. This I believe tells that the PID of the shell did not change, so it's not like neofetch is starting a subshell.... But it could be it's changing the behaviour of the current shell, in some way, maybe? I tried exporting all variables with the "set"-command and comparing them but don't think this is the explanation... But what's it doing then? Also very weird: If I comment "neofetch" out so it won't execute as I start a new shell up, then manually inside that shell run "neofetch" followed by "mc" - then there isn't any issue... Whaaaat? So the issue is there, when it's being called from the sourced file (and only on 1 laptop, not the other, with exact same config) - but not when I run from the command-line? This indicates that maybe it's just some random coincident that it didn't like the "neofetch"-line? In any case, maybe I should add this information to the "mc"-bug tracker... I'm still confused, but obviously happy that now I have some kind of "solution" that doesn't require me to compile from sources... Still a very weird issue, I currently don't have any good ideas as to understanding this better, unfortunately...

seth · 2022-08-23 14:34:13

If I comment "neofetch" out so it won't execute as I start a new shell up, then manually inside that shell run "neofetch" followed by "mc" - then there isn't any issue... Whaaaat?

echo $$ # note down that number
mc # press ctrl+o
echo $$

You could discriminate the invocation by testing "realpath /proc/$PPID/exe"

The trigger might be some control char printed by neofetch, idk - I don't post my desktop on r/unixporn

newsboost · 2022-08-23 15:48:12

seth wrote:

If I comment "neofetch" out so it won't execute as I start a new shell up, then manually inside that shell run "neofetch" followed by "mc" - then there isn't any issue... Whaaaat?
echo $$ # note down that number
mc # press ctrl+o
echo $$
You could discriminate the invocation by testing "realpath /proc/$PPID/exe"

Right, but I don't think it helps so much. It is clear that it works, if I fully remove the .zshrc file and don't do anything at all, but then I also lose a lot of settings. In this case if I run "mc", I get 2 different PID's which also makes sense because then the subshell is working. What I wrote about earlier with "echo $$ ; neofetch ; echo $$" and got the same number, I was just testing if neofetch should open a subshell - but that isn't the case. With .zshrc removed I can do as you suggested and get two different PIDs and it's pointing to two different zsh's.

seth wrote:

The trigger might be some control char printed by neofetch, idk - I don't post my desktop on r/unixporn

Yes, I also got that impression from when reading on that bug-tracker-page. I have a feeling that maybe it's the zsh-prompt or something... But it's generally just completely weird... By the way, I just experienced a bit earlier that my fix didn't work - then I began "bisecting" again and now it works again. Not sure if I made a mistake, but now removing neofetch again is what makes the difference. Weird... Anyways, I'll think about it and maybe make a small comment on that bug-tracker-page, if it can help anyone understand the problem and hopefully fix it, seems zsh has something (maybe a setting or extension/whatever) that can cause problems to "mc"... Thanks for your help!

seth · 2022-08-23 18:19:35

Right, but I don't think it helps so much.

~/bashZsh_source_shell.sh

…
[[ $(realpath /proc/$PPID/exe) == */mc ]] || neofetch

newsboost · 2022-08-24 18:47:40

seth wrote:

[[ $(realpath /proc/$PPID/exe) == */mc ]] || neofetch

Oooh, that is a fantastic solution, thanks a lot (and sorry for the delayed answer, I forgot to check yesterday evening and today I was at work and just recently I got access to the computer)! I did completely as you suggested except I made the check a bit extra strict:

[[ $(realpath /proc/$PPID/exe) == */bin/mc ]] || neofetch

I'll mark as solved, thanks, what a fantastic solution and great help! By the way, now I'm suspicious as maybe "mc" has a very limited initial subshell buffer and it cannot handle too much text output during initialisation and the initial buffer overflows - but I'll write this solution to the bug-tracker-page and maybe this will help, thanks a lot, Seth, you made my day and fingers crossed the upstream bug will be fixed and maybe this can help them find a better solution than this excellent work-around!

Arch Linux

#1 2022-08-23 08:38:41

[SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

#2 2022-08-23 11:43:58

Re: [SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

#3 2022-08-23 14:04:55

Re: [SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

#4 2022-08-23 14:34:13

Re: [SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

#5 2022-08-23 15:48:12

Re: [SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

#6 2022-08-23 18:19:35

Re: [SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

#7 2022-08-24 18:47:40

Re: [SOLVED] Midnight commander subshell (CTRL+O) works on only one laptop

Board footer