Broken PS1 prompt when using mksh

[clipcarl]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

GNU Midnight Commander 4.8.33
Built with GLib 2.84.1
Built with S-Lang 2.3.3 with terminfo database
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 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;

Operating system

Linux clip 6.17.4-0-stable #1-Alpine SMP PREEMPT_DYNAMIC 2025-10-21 08:38:12 x86_64 GNU/Linux

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

1. Set your shell to mksh
2. Set PS1 variable. Fox example to: PS1='$PWD $ '
3. Run Midnight Commander
4. Observe the PS1 prompt displayed by the subshell

Expected behavior

The PS1 prompt displayed by the subshell should be displayed properly. Variable and command substitution should work as expected.

Actual behavior

The PS1 prompt displayed by the subshell is not displayed correctly. For the example I gave above (PS1='$PWD $ ') it literally displays the string '$PWD $ ' without properly substituting the variable. No variable or command substitutions work.

Additional context

Seems related to feature #4634. Opening this up as a separate bug as the behavior I'm describing is in fact a bug in the current behavior of Midnight Commander and not a desired new feature.

Midnight Commander seems to be doing a lot of unnecessary convoluted things with respect to the PS1 prompt under mksh. As a temporary workaround adding the following to my mkshrc after the point where PS1 is defined fixes things for now by preventing Midnight Commander from overwriting the PS1 variable and preventing it from using its own broken precmd() function (makes PS1 read-only):

# hack to fix Midnight Commander with mksh
if [ "$MC_SID" ]
then
    mc_fixed_precmd() { pwd >&9; kill -STOP $$; }
    PS1="\$(mc_fixed_precmd)$PS1"
    typeset -r PS1
fi

On my system file descriptor 9 always seems to be correct for the workaround but your mileage may vary.

[zyv]

I don't quite get it. Did you test it on master? It doesn't look like you did. The stuff in #4634 isn't even finished, so I don't see how it can cause your problem. I guess you mean to say that now that mksh is supported at all after #3748 in 4.8.33, this support is not working for you?

FYI, there is a lot going on fixing the subshell issues in #4784. It would be great if you could coordinate with @egmontkob . Maybe try stuff in this PR and see if it fixes the problem, and if not, then in any case, any further changes should be on top of this PR.

[clipcarl]

@zyv I tested on the current release (4.8.33). I'm reporting the bug that the current release does not work properly with mksh as there appears to be no current bug report for this issue. It should be pretty straightforward for you to test and see for yourself.

[zyv]

I tested on the current release (4.8.33). I'm reporting the bug that the current release does not work properly with mksh.

Okay, this clears it up, so the reference to #4634 was just wrong.

It should be pretty straightforward for you to test and see for yourself.

It absolutely isn’t. I don't use mksh, and I don't even have it on my machine. I could, in theory, install the same environment as the user (in as far as possible) for every single report and try to reproduce what they say, but this would take more time than it would be ever possible for me to make to contribute to this project. This is why answering questions and trying things out really helps. If you don't want to cooperate, that's fine; it's your thing. But obviously, it will affect how your problem will be solved and whether it is going to be solved at all.

[clipcarl]

Okay, this clears it up, so the reference to #4634 was just wrong.

No, it's not. I'm reporting a bug related to the handling of PS1 and precmd. The feature I pointed to is about cleaning up the handling of PS1 and precmd. So it's obviously related.

I don't use mksh, and I don't even have it on my machine. I could, in theory, install the same environment as the user (in as far as possible) for every single report and try to reproduce what they say, but this would take more time than it would be ever possible for me to make to contribute to this project.

I'm just reporting a bug. If you're too busy to deal with bug reports there's not much I can do about that.

This is why answering questions and trying things out really helps. If you don't want to cooperate, that's fine; it's your thing. But obviously, it will affect how your problem will be solved and whether it is going to be solved at all.

I am answering your questions and cooperating, aren't I? I've taken the time to diagnose an issue, write up a bug report, investigate which tickets are related and share a workaround. Why then are you giving me attitude like that's not enough for you and as if reporting this bug is such an onerous and unreasonable imposition on you?

If you want to work on the bug, work on it. If not I don't care; I have a workaround. I'm not interested in the drama you seem to want to invent here.

[zyv]

Whatever.

[egmontkob]

I can reproduce the bug.

The ongoing prompt-related work is irrelevant, doesn't fix it (yet).

When mksh (in fact, every shell I've seen) prints the prompt, it doesn't simply perform an echo -n "$PS1"-like command, it does much more. It interpretes special symbols, such as $ for $VAR substitution and much more.

In precmd_fallback we copy PS1 into MC_PS1_SAVED, and set our own PS1 which invokes our precmd. In turn, our precmd does basically an echo -n $MC_PS1_SAVED. Therefore special characters don't get interpreted anymore, they're simply echoed.

What we should do: Leave PS1 where it is, as-is, but prepend(!!!) to this our precmd invocation.

Notice another bug (not bug, see below) here: Currently we print the saved prompt first, and do the synchronization afterwards. This is the wrong order. Synchronization needs to come first, for mc to know where the command's output ends and the prompt begins, then the prompt.

Prepending to PS1 is a bit dangerous as in that a nested mc could prepend once more, causing (presumably failing) double synchronization. We'd probably need to rename PRECMD to a bit more specific value like MC_PRECMD just to decrease the chance of an accidental conflict with something irrelevant, and then check for the $($MC_PRECMD) substring in PS1 before prepending (not prepending if already there).

[egmontkob]

Nitpicking:

What's the point in an indirect hop: define PRECMD=precmd and then the prompt contains $($PRECMD)? Couldn't we just simply do $(precmd) in PS1?

[egmontkob]

The wrong order is not, in fact, wrong, but is truly counterintuitive.

The pwd > other_fd and kill synchronization is executed on the spot. Beforehand, the echo $MC_PS1_SAVED does not appear immediately on the screen, it's collected by the command substituion $($PRECMD) in PS1 and is printed when the prompt is fully constructed. This effectively swaps the order to the correct one.

That being said, IMO let's go with the more intuitive order.