mc 4.8.32 slow start on MacOS

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/4625
Reporter	emkaroly (molnarkarol@….com)
Keywords	macOS, slow, sub, shell

I am using mc on linux(ubuntu 22.04) and also on macOS(Sonoma 14.Sequoia 15) on MacOS the start takes several seconds on linux it works fine and start instantly. If I use the "-u"flag on macOS it also start instantly.
The default shell in macOS is zsh if I switch to bash it also start instantly. I don't have any custom bash nor zsh profiles its a fresh new OS installation. The machine is a M4 Pro MacBook Pro 14 with 48GB RAM and 1TB SSD. Behavior is same in default Terminal app and iTerm also.
Also when i do sudo mc I get this error:
common.c: unimplemented subshell type 1
read (subshell_pty...): No such file or directory (2)

[mc-butler]

Changed by emkaroly (molnarkarol@….com) on Jan 6, 2025 at 8:43 UTC (comment 1)

I also tried to remove these files without any change:
/etc/zprofile
/etc/profile
/etc/bashrc
/etc/bashrc_Apple_Terminal
/etc/zshrc
/etc/zshrc_Apple_Terminal

[mc-butler]

Changed by zaytsev (@zyv) on Jan 7, 2025 at 20:00 UTC (comment 2)

Maybe related to #4253. Similar issue on FreeBSD with bash - #4548.

I also do have a couple of seconds startup on macOS with zsh, but it doesn't feel critical to me and can't find time to investigate...

[stopdesign]

I had this issue for years.
It takes 1+ seconds to start even a "naked" zsh (with empty .zshrc), so the issue is not in plugins or heavy zsh configuration.

As a workaround I've been using bash as a subshell for MC:

SHELL=/bin/bash mc

It is related to a persistent command line buffer for a subshell. The current persistent buffer code is expecting a response that zsh never produces, so it just waits (and times out) in the select loop.

I was able to "fix" it by setting:

subshell_prompt_timer.tv_sec = 0;
subshell_prompt_timer.tv_usec = 10;

in /src/subshell/common.c in a read_command_line_buffer function.

Have no idea why do we need this timer to be so large. In my case everything works as it should.

[zyv]

It is related to a persistent command line buffer for a subshell. The current persistent buffer code is expecting a response that zsh never produces, so it just waits (and times out) in the select loop.

Not necessarily. Most likely it either produces it too late, or it's mixed in with other responses, or it's just not parsed correctly. I've already referenced #4253 above, that could be one possibility why this happens.

I was able to "fix" it by setting:

subshell_prompt_timer.tv_sec = 0;
subshell_prompt_timer.tv_usec = 10;

in /src/subshell/common.c in a read_command_line_buffer function.

Have no idea why do we need this timer to be so large. In my case everything works as it should.

Well, obviously it isn't working as it should, because when the timer to read the prompt times out, then the persistent buffer feature is automatically disabled:

mc/src/subshell/common.c

Lines 1667 to 1672 in f55ef44

	/* Try out the persistent command buffer feature. If it doesn't work the first time, we
	* assume there must be something wrong with the shell, and we turn persistent buffer off
	* for good. This will save the user the trouble of having to wait for the persistent
	* buffer function to time out every time they try to close the subshell. */
	if (use_persistent_buffer && !read_command_line_buffer (TRUE))
	use_persistent_buffer = FALSE;

So your "fix" is simply to unconditionally disable the persistent buffer feature without any delay, but keep the basic subshell integration.

[vtmocanu]

Anyone has other workarounds except using bash/recompiling?
I have a lot of customizations for zsh, so having a bash subshell feels somewhat limiting for me :)

[zyv]

Unfortunately, not at the moment. It would take a PR with a proper fix, as opposed to simply increasing the timeouts or disabling this feature altogether.

[wallneradam]

Workaround for MC slow startup on macOS with zsh

Root Cause

The issue is caused by escape sequences output by precmd_functions during MC's subshell initialization. On macOS, functions like update_terminal_cwd write OSC escape sequences (e.g., \e]7;...) to notify Terminal.app about the current directory. These escape sequences confuse MC's subshell initialization, causing it to wait for the full 10-second timeout.

Related Issues

• This issue (mc 4.8.32 slow start on MacOS #4625) - escape sequences from precmd_functions
• Issue Interference of injected subshell commands output with e.g. read in .zshrc causing 10s startup delay #4253 - read commands in .zshrc interfering with MC's subshell commands

Both cause the same 10-second delay but have different root causes.

Quick test to confirm

You can verify this is the issue by adding this single line to your .zshrc:

[[ -n $MC_SID ]] && precmd_functions=()

If MC starts instantly with this line, then precmd_functions is the culprit.

Why it happens

1. MC starts and initializes a zsh subshell
2. When starting from a non-home directory, zsh runs precmd_functions
3. These functions output escape sequences (like ^[]7;file://...)
4. MC's subshell initialization gets confused by these escape characters
5. MC waits 10 seconds (timeout) for a clean response
6. After timeout, MC shows a broken prompt (e.g., ^[_)

Solution - Filter escape sequences in .zshrc

Instead of disabling all precmd_functions, we can filter out just the escape sequences:

# Detect if we're running under MC
if [[ -n $MC_SID || -n $MC_TMPDIR ]]; then
    # Only wrap once
    if [[ -z $_MC_PRECMD_WRAPPED ]]; then
        # Save original precmd functions
        _MC_ORIGINAL_PRECMD=($precmd_functions)
        
        # Wrapper that filters escape sequences
        _mc_filtered_precmd() {
            local func output
            for func in $_MC_ORIGINAL_PRECMD; do
                output=$(eval "$func" 2>/dev/null)
                # Only output non-escape sequences
                if [[ $output != $'\e'* ]] && [[ $output != $'\033'* ]]; then
                    [[ -n $output ]] && print -n "$output"
                fi
            done
        }
        
        # Replace precmd_functions with filtered version
        precmd_functions=(_mc_filtered_precmd)
        export _MC_PRECMD_WRAPPED=1
    fi
fi

Note: If you have read commands in your .zshrc that query the terminal (see issue #4253), you may need to wrap those in a check to skip them under MC:

if [[ -z $MC_SID ]]; then
    # Terminal query commands here
    print -nr $'\e[6n'
    read -Asd R -- reply
fi

Results

• ✅ Instant MC startup (no 10-second delay)
• ✅ No broken prompt (^[_ characters)
• ✅ Full zsh functionality preserved
• ✅ Works from any directory
• ✅ No need to recompile MC or modify timeouts

Why other workarounds work

• mc -u disables subshell → no initialization issue
• Starting from home directory → no chpwd trigger → no escape sequences
• Using bash → different initialization, no problematic precmd_functions
• Setting SHELL=/bin/bash mc → uses bash subshell instead of zsh

This solution addresses the root cause without disabling functionality or modifying MC's source code.

Tested on:

• macOS Sequoia 15 (Apple Silicon M4)
• MC 4.8.31, 4.8.32, 4.8.33
• zsh 5.9

Note: The issue may not appear on all systems - it depends on what precmd_functions are configured in your zsh setup. Intel Macs might not exhibit the problem if they don't have the problematic Terminal.app integration functions.

[zyv]

@wallneradam thank you for the analysis, but I think that you are wrong about part of it.

Specifically, the root cause seems to be that communication from the subshell to mc regarding the current subshell directory via the precmd hooks interferes with the communication from mc to the Terminal app via OSC 7 regarding the current directory in mc.

Our communication in both directions is very fragile and racy. It seems that the proper solution would be to try to isolate communication channels and/or create some higher level protocol which will make it possible to resolve overlapping communication. I think this is what #4253 is all about.

However, in practice, I think that the current (broken) situation was provoked by merging #3088, which enabled the support for OSC 7 sequences. You can check this by commenting the insides of the update_terminal_cwd function.

@egmontkob is there any chance you could look into "unbreaking" zsh after your patch? I guess the problem pertains to all subshells, it's just that zsh is most likely to be extended with heavy plugins and is generally somewhat slower.

The dream solution above is probably much work, but maybe you can see a way to postpone directory reporting until the subshell stuff has been properly and completely initialized?

[wallneradam]

@zyv Thanks for the feedback! You're right that the communication is more complex than I initially described.

However, I think we're actually talking about the same root cause from different angles:

1. Your perspective: MC's OSC 7 sequences (from Tell the current directory to gnome-terminal #3088) interfere with subshell communication
2. My observation: The precmd_functions output escape sequences that confuse MC's subshell initialization

The key insight is that various zsh plugins and system functions add hooks to precmd_functions that output escape sequences. Common culprits include:

• update_terminal_cwd (macOS system function that outputs OSC 7)
• zsh-autosuggestions
• zsh-syntax-highlighting
• Other popular zsh frameworks/plugins

When MC initializes the subshell, these functions run and their escape sequence outputs interfere with MC's initialization, causing the 10-second timeout.

Why the workaround works:

• By filtering escape sequences from precmd_functions, we prevent any problematic output from interfering
• This effectively "unbreaks" the initialization without needing to modify MC's source
• Works regardless of which specific plugin/function is causing the issue

You're absolutely right that a proper fix would be to improve the communication protocol. But until then, this .zshrc workaround provides immediate relief for affected users.

I'd be happy to test any patches that address this at the MC level!

[egmontkob]

I can't see how #3088 could have caused this issue.

3088 is between mc and its host terminal. mc sends a whole lot of things to its host terminal: switches to the alternate screen, paints the entire screen, enables mouse, sets the xterm window title, and now also sets the terminal's concept about the current working directory (OSC 7): a one-way communication that the host terminal can ignore or use as it wishes to.

The problem discussed here occurs between mc and its subshell. That's a different communication channel.

Now, it might happen that the subshell also decides to use OSC 7 to tell the working directory to its terminal, which terminal is mc in this case, and mc fails to recognize that sequence and in turn fails to recognize the received prompt, leading to the wait. So maybe it's the same type of escape sequence, but definitely at a different place.

@wallneradam's root cause analysis looks correct to me. His solution I'd rather call workaround [edit: he posted his last comment while I was typing this one, and now he also calls it a workaround, we're on the same page], and is also out of mc's reach. The solution would be to teach mc's subshell initialization code to recognize and ignore certain frequently seen escape sequences, such as OSC ... ST and OSC ... BEL, DECSET/DECRST (e.g. bracketed paste), and whatever else that people report to cause problems.

[zyv]

I can't see how #3088 could have caused this issue.

I see, thanks for your explanation, @egmontkob! @wallneradam tripped me up with his mention of update_terminal_cwd, but you are right. Apparently it's really zsh that is generating the OSC 7 sequences to talk to mc and not the other way around, and it has nothing to do with the precmd hooks per se or update_terminal_cwd for that matter.

I wonder what the situation is with fish then... @krobelus did some work in #4663 to parse CSI sequences. So maybe this can be somehow extended to parse (and ignore) OSC sequences?

On a related note, the precmd hooks do two things according to my understanding:

1. Report the current directory for synchronization
2. Report the current buffer and cursor position for persistent buffer mode

At least (1) can then be replaced with OSC 7 for a subshell that is ready to report its current directory changes to its terminal (in this case, mc)... I wonder if there is anything like that for (2).

[egmontkob]

At least (1) can then be replaced with OSC 7 for a subshell that is ready to report its current directory

This is an area I'm totally unfamiliar with, just trying now to see if I can make some sense out of it. init_subshell_precmd() seems to be quite relevant.

Seems to me that there are three channels. In addition to where the subshell commands' stdout goes, there's subshell_pipe for the working directory, (1) in your list, and command_buffer_pipe for something cursor-related, apparently (2) in your list.

The point is: currently there's a separate channel where the working directory is sent to. This is totally clean and robust. There's no point whatsoever in switching to the OSC 7 container format here on this channel. You could merge it to the main channel with the OSC 7 syntax but then you'd have to parse that entire flow and locate that sequence, which sounds quite complicated, fragile and slow.

I'd just keep the current architecture of reporting the working directory over the separate channel of subshell_pipe.

Whichever part of mc parses the main channel's traffic and magically tries to locate the prompt (because that has to go to main data channel, cannot have its own separated one) should just simply recognize and ignore any OSC. (Not sure why this doesn't happen automatically, what is so special in an OSC 7 that fools the code trying to locate the prompt, I haven't looked at that code.)

[krobelus]

if the people who can reproduce this could insert some log statements to confirm the root cause, that would be great.
I'm mainly confused by this claim:

MC's subshell initialization gets confused by these escape characters

which doesn't make sense to me because mc doesn't do anything with the shell's stdout at least until the first time ctrl-o is pressed (and then all it does is write it to the enclosing terminal).

AIUI, we're hanging for 10 seconds
in feed_subshell() on zsh startup.

We're waiting until the first successful read from

    // Read the subshell's CWD and capture its prompt
    {
        const ssize_t bytes = read (subshell_pipe[READ], subshell_cwd, sizeof (subshell_cwd));

where "subshell_state" is set to "RUNNING_COMMAND".

The shell's stdout is read in
read (mc_global.tty.subshell_pty, pty_buffer, sizeof (pty_buffer))
around line 900.

This should not affect "subshell_state" at all.
Today, mc doesn't parse the shell's stdout
but simply ignores all of it (unless (how == VISIBLY)).

FWIW, fish writes a lot of commands on startup, including OSC 0, OSC 7 and OSC 133 commands, no problem here.

(I'm also working on a change that will make mc parse the shell's stdout to respond to the primary device attribute,
to make it more compatible with actual terminals.. let's hope that works out..)

[krobelus]

Ah I missed that there is read_subshell_prompt() which does actually read the shell's stdoud (read (mc_global.tty.subshell_pty line ~1800). But I'm not sure what it's looking for exactly that causes delays