Wednesday, November 21, 2007, 4:01:26 PM, you wrote:
> On Wed, 21 Nov 2007 14:36:15 +0100 "Pavel Tsekov" <[email protected]> wrote:
>> Do you refer to the notorious "The shell is already running a command" issue
> Yes, this one exactly.
Ok. Yes - it is really hard to fix. You've been around for many years
now so I'd expect you to know more about this issue. Anyway...
What makes this problem really hard to fix is that MC doesn't really
know what's going on the subshell side. The subshell code is all about
passing user input to the shell and reading its output. There is a bit
of code dealing with prompt retrieval and some state tracking. MC
employes a feature of the shells it supports to understand when
the shell has completed executing a command - it sets up thing so
that a STOP signal is send to the shell just before it displays each
prompt. Sending a STOP signal triggers the OS to send a SIGCHLD signal
to MC - when it gets the signal it knows that the subshell completed
executing its task.
Now... Most of the time it is not apparent to the people complaining
about this issue why MC presents a dialog box and this makes it
especially irritating. It is not obvious because for some reason, while
in the subshell they typed something, but their input didn't get executed
by the subshell and the subshell is waiting for more input - so
everything seems normal but they still get the nasty message. Now..
there is no real fix in this situation. We cannot just discard
the pending input. We cannot send the new command to the subshell
since it just won't work or even worse it could cause unpredictable
results. It would be easier if the subshell did some kind of
input parsing but then it would become overly complicated... The
most simple solution would be to pass input once the code sees
a newline but then features like Tab-completion and others won't
work and people will start complaining about that. It really is not
that simple to fix it. And it really isn't and error.
Mc mailing list