Subshell/Command line prompt is empty/missing #3121
Comments
Sorry, but I'm unable reproduce this bug. |
|
Ok, let step by step.
Is it happened immediately after start or after any actions? |
OK, I've made additional tests. I was wrong about bash, it happens only with zsh. $PS1 is irrelevant as see this behavior with empty zshrc. Though it happens, but not so often. Usually this happens with mc start and the prompt may appear on dir change ...or may not. From my perspective it's more like race condition somewhere and the heavier my zshrc, the often it happens.
Just in case you can check my zshrc at https://github.com/z0rc/dotfiles/blob/master/zshrc.
I'll try to dig into gdb later this week. |
I can't reproduce, just looking at the code, but line 1022: g_string_set_size (subshell_prompt, 0) is fishy, it's inside the while(select(...)) loop that takes care of assembling multiple short reads, but I guess it should be before that loop. |
|
Replying to egmont:
This was fixed in #3001. |
I'm continuing my investigation. Current situation:
This is strange as at directory change we enter setup_cmdline two times, first enter with correct prompt, second with bogus. At second break I can see the valid prompt in mc, which later gets changed to nothing. I'll continue to dig this up. If you have any hints, please share. |
I think you should check subshell_prompt in read_subshell_prompt(). |
Please close this as invalid. It appears my problem after all. Though it wasn't obvious to spot. Basically zsh has two prompts: left and right, mc was interpreting both of them. I had an option to set RPROMPT to be "" (empty string) if zsh is running under mc, it was working just fine. Right now I have to completely undefine RPROMPT, so mc won't interpret it. |
|
I spoke to soon and reopening this ticket. Sorry.
RPROMPT has nothing to do with this as it won't affect the situation, as I though initially. "\033[?1h\033=" is present always, event when RPROMPT isn't set. This looks like mark of prompt end, as they present event with empty PROMPT.
I still think this is some kind of race condition. I can catch empty prompt comes after valid when setting up just watch on subshell_prompt variable. But when I break on read_subshell_prompt the empty shell won't appear and issue won't show up. Also I cannot catch issue under strace, then mc behaves just fine. |
|
no prompt (happens after typing ls -> enter several times) |
.zshrc from manjaro forum which probably do not depend on manjaro-zsh-config package and can be probably used on plain Arch |
This still happens with config from manjaro-zsh-config package in 5.4.15-2-MANJARO. The prompt is approx. 9 out of 10 times there but once in a while after typing a command (like ls) it is gone. To bring it back one has to type some command again (one or more times).
This is the standard config from manjaro-zsh-config and can be found in /etc/skel/.zshrc after installing manjaro-zsh-config package.
I've created a topic on a forum: https://forum.manjaro.org/t/prompt-disappears-in-zsh-mc-after-typing-comands-sometimes/122552 but I think this may be also an issue with mc vs zsh, which is to be fixed in mc.
To reproduce the issue one should use the config attached https://github.com/MidnightCommander/trac-archive/blob/master/attachments/ticket/3121/.zshrc (I'm not sure it will work without the full manjaro-zsh-config package though and that this package can be installed on plain Arch easily, however the issue is also reproducible with the another config: https://forum.manjaro.org/t/unstable-manjaro-zsh-config/17899/105 (which seems to be not "Manjaro-specific" and is attached as https://github.com/MidnightCommander/trac-archive/blob/master/attachments/ticket/3121/.zshrc_arch) and then type "ls -> enter > ls -> enter..." until prompt is gone. This does not always happen but often enough (1 times out of 10 approx). By "does not always happen" I mean that it always happens if you will type "ls -> enter" enough for it to happen. But how many times one has to do it is random. I confirm that it seems like a race condition. It does not happen without .zshrc file at all.
I'm using xfce4-terminal, but this also happens in xterm (see https://github.com/MidnightCommander/trac-archive/blob/master/attachments/ticket/3121/prompt_sometimes_disappears.png).
I have a workaround for this based on the comment: #3121?cnum_edit=16#comment:10 in .zshrc:
but this removes some goodies one make for git in RPROMPT. |
I'm using zsh with mc and I have disabled rprompt for mc. But I still have empty prompt sometimes. It seems that zsh adds empty line from time to time. There is already check in mc in set_prompt_string function, but zsh adds empty line with escape sequences. I've created simple UGLY patch and now prompt works as expected with zsh and git goodies: |
Replying to kvaster:
It would be great if you provide more or less detailed description about your code. |
It seems to me that patch in comment:17 does the same as function strip_ctrl_codes(). |
Hi all. I'll just add that I can confirm I've also just experienced this issue and then add a simpler workaround that doesn't require any compiling of source code (alternative and easier work-around than #comment:17 (#3121)):
First my system:
Fully up-to-date Arch Linux running with Midnight Commander 4.8.28 and I also use zsh. Interestingly enough I actually have 2 laptops with exactly the same configuration (~/.zshrc and a sourced config-file common to zsh and bash). But this CTRL+O subshell issue only happened on one of the pc's (don't know why, it's very strange because both runs uptodate Arch Linux, so the difference should mostly be hardware and maybe minor differences in installed packages although most is the same).
"Work-around solution":
I ended up with first disabling the last command in my startup zsh-config: "neofetch" - later I changed it to this: [[ $(realpath /proc/$PPID/exe) == */bin/mc ]] || neofetch
which effectively prevents "neofetch" from running when the CTRL+O starts a subshell, which was the culprit on my system.
Concluding remarks:
UPDATE: The above workaround does not always work - this works (on my system): mv -i .zshrc .zshrc__
which is also how I found the above-mentioned work-around (by "bisecting", i.e. commenting things out until I could see what did the difference).
UPDATE 2: The comment no.17-workaround does not work on my system
I just tried applying the patch described at #3121 comment 17 and it made a difference: Now I got colors instead of black/white and furthermore I don't get any annoying "Error. Unable to load 'default' skin"-startup error. So my expectations were high, but unfortunately this patch does not fix my CTRL+O (subshell) issue... hmm. I understand this issue is difficult to track down as many people cannot reproduce it. If you have any ideas for what I could try, to get a better understanding, please write, I would be happy to help as I'm a long-time user of "mc" and with it should be bugfree...
UPDATE 3: Preliminary learnings with GDB
I've currently applied the comment no17-patch and just learned from searching a bit that init_subshell()-should be a breakpoint-place but also execute.c:491 and 501. I attached to the PID of the compiled mc (incl patch-17) and hit CTRL+O and now I can see what happens:
I would need to understand better why the situation above has happened, this will not be today, I'm a bit tired now. Anyway, if I should test anything or if you have ideas, please write (I hope I'll receive an email notification?) and I'll try it out so this weird zsh-issue can be fixed, I hope this helps... |
|
Do not work SubShell for me. :(
My environment: |
Same problem exists in cygwin on official Windows Terminal Console using the official cygwin package (mc 4.8.27 with subshell support):
When I start from there with mintty mc then everything is working fine (ctrl-o opens a screen, I can edit there and the rc file has been sourced successfully.
Apparently mc has issues with some terminal clients? |
Debugging revealed that when the subshell is initialized, the feed_subshell function returns FALSE.
To fix this, you can add an additional parameter to the feed_subshell function indicating that it is initializing and needs to wait longer. |
tonal is correct. Line 752 in 3250536
If your profile loads slower than 1 second - you have no subshell. |
|
|
|
The problem still exists in 4.8.29. I think I know why and have a patch with a reliable fix. From my commit message:
When using zsh with https://starship.rs prompt generator, MC sometimes fails to show the subshell prompt. This is not deterministic. Sometimes the prompt is shown and sometimes it isn't.
The reason is that the shell prints the prompt in multiple chunks. The first chunk contains the "real" prompt and the second is an escape sequence for enabling bracketed paste mode. If both chunks are read by MC in a single invocation of read_subshell_prompt(), the prompt is shown correctly. If, however, read_subshell_prompt() reads each chunk in separate invocations (because the second chunk is not ready during the first invocation), the prompt is not shown. More precisely, only the bracketed paste mode escape sequence is shown as a prompt in MC.
This can be demonstrated with the following commands:
In my case, the prompt is usualy shown after mc start and it disappears after changing a directory in mc. In that case, the prompt is read() in the following two chunks:
To fix the problem, we remove clearing of the prompt string in read_subshell_prompt(). It is sufficient that the prompt is cleared when receiving '\n' and in feed_subshell().
I'll attach the patch here. Let me know whether this is sufficient of a Github PR is more appropriate these days. |
|
Thanks!
Branch:3121_empty_subshell_prompt |
|
Important
This issue was migrated from Trac:
z0rc(z0rc3r@….com)egmont@….com(@egmontkob),congest(hydrogenbuilding@….com),aurrak(aurrak@….com),reagle(joseph.2011@….org),tonal.promsoft@….comsubshellSee attached screenshot. The issue persist with TERM=(xterm|screen).*. Tested with konsole and xterm both on current Debian Sid, Ubuntu 12.04 and Ubuntu 13.10. Tested with bash and zsh. The issue doesn't exists with 'linux' terminal (without xorg, plain console at Ctrl+Alt+F1)
I bisected issue to:
Note
Original attachments:
z0rc(z0rc3r@….com) onDec 9, 2013 at 21:57 UTCxor512(siergiej.riaguzow@….com) onFeb 4, 2020 at 4:31 UTCxor512(siergiej.riaguzow@….com) onFeb 4, 2020 at 4:33 UTCxor512(siergiej.riaguzow@….com) onFeb 4, 2020 at 4:47 UTCwentasah(michal.sojka@….cz) onMar 11, 2023 at 8:06 UTCThe text was updated successfully, but these errors were encountered: