Changed by adminX (mc-trac@….de) on Mar 17, 2010 at 12:28 UTC (comment 1)

• Cc set to mc-trac@….de

Changed by zaytsev (@zyv) on Mar 18, 2010 at 8:17 UTC (comment 2)

• Cc changed from mc-trac@….de to *mc-trac@….de, zaytsev, *

Unfortunately, I have also stumbled upon this issue quite a few times. My vote here.

Changed by andrew_b (@aborodin) on Jul 11, 2010 at 9:37 UTC (comment 3)

• Version changed from version not selected to master

See also #2269.

Changed by ossi (@ossilator) on Jul 11, 2010 at 9:43 UTC (comment 4)

• Cc changed from *mc-trac@….de, zaytsev, * to mc-trac@….de, zaytsev, ossi@….org

Changed by jmak (@jmakovicka) on Feb 23, 2011 at 18:36 UTC (comment 5)

'The shell is already running a command' was annoying, but this "solution" only calls for shooting oneself in the foot. I just managed to make a svn commit with a bogus message only because I wanted to review something before smashing enter.

I added -u to mc's parameters. Executing commands without user's content, and with bogus arguments is just too dangerous.

Changed by andrew_b (@aborodin) on Nov 7, 2011 at 12:01 UTC (comment 6)

• Branch state set to no branch
• Milestone changed from 4.7 to Future Releases

Changed by andrew_b (@aborodin) on Mar 23, 2013 at 5:17 UTC (comment 7)

See also #2987.

Changed by onlyjob (@onlyjob) on Mar 23, 2013 at 5:29 UTC (comment 8)

• Cc changed from mc-trac@….de, zaytsev, ossi@….org to mc-trac@….de, zaytsev, ossi@….org, onlyjob@….fsf.org

Changed by ossi (@ossilator) on Jan 5, 2014 at 16:47 UTC (comment 9)

an attempt to fix the problem properly was made at https://mail.gnome.org/archives/mc-devel/2004-November/msg00199.html

another related thread is https://mail.gnome.org/archives/mc-devel/2006-July/msg00013.html

Changed by ossi (@ossilator) on Jan 5, 2014 at 16:49 UTC (comment 10)

fwiw, there is also https://mail.gnome.org/archives/mc-devel/2006-May/msg00030.html which contains a somewhat related patch that should be looked at.

Changed by onlyjob (@onlyjob) on Dec 13, 2014 at 6:58 UTC (comment 11)

In the https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703741#16

Dmitry Borisyuk proposed the following patch:

A simple solution for this problem is to send C-k C-u to the shell
before sending 'cd' command, which will erase previous unfinished text
(C-k is needed for bash if the cursor is in the middle of the line).
I've tried the following patch with bash, zsh and tcsh and it works fine.

--- a/src/subshell.c
+++ b/src/subshell.c
@@ -1190,7 +1190,7 @@
 
     /* The initial space keeps this out of the command history (in bash
        because we set "HISTCONTROL=ignorespace") */
-    write_all (mc_global.tty.subshell_pty, " cd ", 4);
+    write_all (mc_global.tty.subshell_pty, "\013\025 cd ", 6);
 
     directory = vfs_path_to_str (vpath);
     if (directory != '\0')

Please review.

Changed by ossi (@ossilator) on Dec 13, 2014 at 11:36 UTC (comment 12)

as a band-aid, the idea isn't bad.
note that the order c-k c-u is important, as a plain tty (as used by ash, for example) will not interpret c-k (but it will interpret c-u).

however, i don't consider this a real solution - it's destructive, after all.
imo, the original patch should be reverted, and a more robust way of detecting shell idleness devised. that could be probably done by looking closer at the shell's tty output, so we can actually know when nothing is on the prompt.

Changed by and on Dec 28, 2015 at 20:05 UTC (comment 13)

summary subshell

mc open one (sub)shell for read/write (subshell_pty)
mc open one fifo for reading by mc and writing by (sub)shell (subshell_pipe)
mc init (sub)shell interpeter with custom precmd shell code
precmd is triggered at each (sub)shell prompt (doing by shell interpreter)
precmd writes CWD info to given fifo (subshell_pipe)
mc subshell is always running
mc subshell can be visible/invisible (aka Crtl-o aka subshell_state?)
subshell_ready?

after (sub)shell init, mc can send command to (sub)shell itself
for example string " cd " will send when panel toggles

This can be bad because mc cannot see if (sub)shell is ready to accept next shell cmds
for example shells can have page-completions which except certain input response (#2269)
now toggle panel, mc write "cd" to issue precmd but no new fifo data arrived, BOOM.

It must be prevented that mc write shell commands itself in unclear situations.

What is a unclear situation?

• user input sended to (sub)shell, no fifo/CWD data arrived yet

What is a clear situation?

• (sub)shell init done and fifo/CWD data just arrived, no user input sended to (sub)shell yet
• fifo/CWD data arrived and no user input sended to (sub)shell yet

proposal:

• subshell_init_done flag TRUE/FALSE
  • TRUE: init process complete (with optional "cd" test successful)
  • FALSE: init process not done yet (will block all mc subshell user functions)

• subshell_visible flag TRUE/FALSE
  • TRUE: (sub)shell visible
  • FALSE mc panels visible

• subshell_busy flag TRUE/FALSE
  • TRUE: user input sended
  • FALSE: fifo/CWD received

• toggle panel
  • subshell_busy=TRUE:
    • no mc data aka "cd" send to (sub)shell
    • when user enter data for (sub)shell inform user with a msgbox
  • subshell_busy=FALSE:
    • mc issue "cd" command
    • send user data to (sub)shell if available (and set subshell_busy=TRUE)
• reading fifo/CWD
  • after reading fifo/CWD set subshell_busy=FALSE

• after fresh (sub)shell init do a test "cd" cmd to detect if fifo/CWD working properly if not, give up (sub)shell handling earlier than later

What I miss?

Changed by zaytsev (@zyv) on Sep 19, 2020 at 11:20 UTC (comment 14)

• Blocked by set to #4114

Changed by andrew_b (@aborodin) on Sep 27, 2020 at 16:53 UTC

• Blocked by #4114 deleted

(In #4114) Merged to master: [c22387d].

Changed by andrew_b (@aborodin) on Sep 27, 2020 at 16:56 UTC (comment 16)

• Resolution set to fixed
• Status changed from new to closed
• Milestone changed from Future Releases to 4.8.26

Changed by andrew_b (@aborodin) on Sep 27, 2020 at 16:58 UTC (comment 17)

Fixed in #4114.

Changed by zaytsev (@zyv) on Feb 21, 2025 at 7:56 UTC (comment 18)

Ticket #2987 has been marked as a duplicate of this ticket.