[email protected]
[Top] [All Lists]

Re: A good old well-known itchy thing

Subject: Re: A good old well-known itchy thing
From: Michelle Konzack
Date: Thu, 29 Nov 2007 18:47:32 +0100
Hello Pavel,

Am 2007-11-21 21:06:17, schrieb Pavel Tsekov:
> 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.

The problem is, sometimes it is working and sometimes not.

So, if I run a Shell-Script, I exit the script explicit with an

    exit 0

of another Exit-Code.  It seems, the "exit" at the end of a script
CAN SOLV the problem partialy.

> 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

..and it seems, that they are programs which won't run in a DUMB
terminal and THEY NEED a tty.  So, if you switch back to "mc" the
program become confused and is blocking the sub-shell.

> 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.

FullACK!

Thanks, Greetings and nice Day
    Michelle Konzack
    Tamay Dogan Network
    Open Hardware Developer
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSN LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)
_______________________________________________
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc
<Prev in Thread] Current Thread [Next in Thread>