Subshell with Fish not working?

[molnarti]

I have recently switched to Garuda linux as my main desktop OS which comes with Fish shell out of the box. I realized that the subshell command (Ctrl+O) in MC is not working properly. The subshell just shows the console output, but i cannot type in anything. Pressing any key just sends me back to MC.
Is this a known issue with fish? Any fix on the horizon?

EDIT:
I am on MC 4.8.33 and fish 4.0.8

 mc -V
GNU Midnight Commander 4.8.33
Built with GLib 2.82.4
Built with S-Lang 2.3.3 with terminfo database
Built with libssh2 1.11.1
With builtin editor and aspell support
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, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;


fish --version
fish, version 4.0.8

[mc-worker]

Unfortunately, you didn't provide any info about mc you are using. Please show the output of mc -V command.

[molnarti]

i have built the version from master and the issue is the same . it works on bash shell, the problem looks to be related only to fish

GNU Midnight Commander 4.8.33-348-g1c32c69f6
Built with GLib 2.86.0 (using GLib 2.86.0)
Built with S-Lang 2.3.3 and terminfo database (using S-Lang 2.3.3)
Built with libssh2 1.11.1
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 ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;

[zyv]

@krobelus do you happen to have any idea how to debug this further?

[zyv]

If I were you, I would create an empty user and check that mc starts with the fish shell and no customizations...

[molnarti]

turns out the subshell is broken by a very elaborate fish customization Garuda Linux comes with, specifically running of neofetch everytime a shell is opened. once i commented out the particular lines in ~/.config/fish/config.fish subshell works without any issues

## Run fastfetch if session is interactive
# if status --is-interactive && type -q fastfetch
#   fastfetch --config dr460nized.jsonc
# end

[zyv]

Thanks for getting back to us! Perhaps you could raise the issue with them? It's not nice when mc doesn't work out of the box.

[molnarti]

will try to. posted about it in the Garuda forums, but the actual issue will need some additional investigation. it seems weird that just calling fastfetch itself would break it, rather it might be in the specific config used for neofetch.
but i agree, its especially annoying with a distro comes with a config out of the box that breaks mc - also other user confirmed on the garuda forums that he has the same issue.
it turns out there are people who can somehow live without having mc installed as their first thing , otherwise i cannot explain why this went unnoticed.

[molnarti]

so, to be precise, the issue is caused by the fact that the fastfetch configuration in garuda renders a png logo in the terminal. when that logo is rendered, it breaks something in the terminal and MC subshell stops working.
interestingly, it only breaks when the logo is rendered immediately on starting the fish session, not when i run the same command from the terminal after startup.

oh, and i am using Konsole, but the issue is the same in Alactritty, despite the fact that its not able to actually render the png logo.
this is the fastfetch config in question:
dr460nized.jsonc

[zyv]

Maybe it's somewhat similar to #4625, only for fish :(

In short, we inject our hooks into the subshell in question, and if the timing is wrong, a deadlock occurs. Eventually, mc hits the timeout and starts without the subshell. This is (more) prone to happen with heavy and/or customized init scripts.