Slow start because the subshell starts slow

[aleb]

On my system (Archlinux, zsh with oh-my-zsh) mc starts in 4-5 seconds which is very noticeable. When I remove ~/.zshrc, mc starts instantly.

GNU Midnight Commander 4.8.15
With subshell support as default
With support for background operations

It might worth to start the subshell on a background thread to be able to show the main UI faster. Then a rotating dash would be displayed in the command prompt and in Ctrl-O until the subshell is ready.

How can I help to add this enhancement?

[and]

sounds like mc has trouble to detect your shell or zsh precmd_functions are botched or zsh version is too old.

after mc start at subshell

$ echo $SHELL
$ echo $ZSH_VERSION
$ echo $precmd_functions
$ declare -f _mc_precmd

[aleb]

After I start mc and Ctrl-O:

$ mc

$ echo $SHELL
/bin/zsh

$ echo $ZSH_VERSION
5.2

$ echo $precmd_functions
omz_termsupport_precmd _mc_precmd

$ declare -f _mc_precmd
_mc_precmd () {
        pwd >&8
        kill -STOP $$
}

(BTW, I found out the slow start of the shell was because of the large ~/.zsh_history file)

[and]

that must be a huge ~/.zsh_history indeed :)

[ag]

I've been hunting with strace for this bug. And it has been indeed already reported. My .bash_history is 3.5M. After

mv -i ~/.bash_history ~/.bash_history.bak

mc starts promptly. Can be 3.5M considered as huge?.. At least for bash it is so. It starts with a delay.

Using strace I've identified a couple of critical places. The following call takes the most time:

src/subshell.c

// ...cut...

    /* Set up `precmd' or equivalent for reading the subshell's CWD
     *
     * Attention! Never forget that these are *one-liners* even though the concatenated
     * substrings contain line breaks and indentation for better understanding of the
     * shell code. It is vital that each one-liner ends with a line feed character ("\n" ).
     */

    switch (subshell_type)
    {
    case BASH:
        g_snprintf (precmd, sizeof (precmd),
                    " PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND\n}'pwd>&%d;kill -STOP $$'\n"
                    "PS1='\\u@\\h:\\w\\$ '\n", subshell_pipe[WRITE]);
        break;

// ...cut...

    write_all (mc_global.tty.subshell_pty, precmd, strlen (precmd)); // <-----------------------

// ...cut...

[zaytsev]

As you can see, all this does is to send our precmd hook to the shell, which we need in order for the communication with subshell to work, so on the mc side, it doesn't actually need any time at all, but rather it blocks at the shell end.

I think you should be able to simply run it in the terminal and see how much time does it take... (or else extract in a small stand-alone program). I have no idea why shells don't seem to like it if they have huge histories, but you can try to find out.

[egrep]

strace -r -tt -o mc.strace -y mc

[egrep]

Hello!

I have the similar issue. mc takes about 10-20 seconds to open. I attached the trace obtained using:

strace -r -tt -o mc.strace -y mc 

Take a look at 911-912 lines:

19:04:11.771476 (+     0.000032) pselect6(4, [3</dev/tty>], NULL, NULL, NULL, NULL) = 1 (in [3])
19:04:31.676103 (+    19.904637) rt_sigaction(SIGINT, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f75475292e0}, NULL, 8) = 0

20 sec for pselect6

[egrep]

I finally pinpointed the problem. It was in hiding in .inputrc.

"\C-j": menu-complete-backward

Assigning \C-j to other functions also causes a slow startup.

[zaytsev]

egrep, thanks for your investigation; midnight commander sends c-j to the shell to clear the buffer - if you reassign it, you break the shell support. I don't think that we can do anything here.

The other problem relates to big shell histories, but here I don't think we can do anything either if the shell is slow to start. I would close this ticket for now - I don't think that these are problems in mc that we can do anything about.

[zaytsev]

Custom prompts and similar projects started to be friendlier to us by checking MC_SID.