Re: Makeing the subshell reliable

[Pavel Tsekov <ptsekov gmx net>]

On Thu, 13 Jul 2006, Oswald Buddenhagen wrote:

> On Thu, Jul 13, 2006 at 04:29:35PM +0300, Pavel Tsekov wrote:
> > There are several features which are consistent source of problems:
> >
> > My opinion is that we should remove both features from the subshell.
> >
> >    * the subshell prompt retrieval - this one is widely known to be
> >      unreliable.
> could you be more precise about that? do you mean the shell's cwd or the
> actual prompt string?

The shell prompt string itself. The current implementation is flawed. Some 
weeks ago I posted a patch witch tries to improve it. The patch would make
the things better but still not perfect. At least not until commands 
typed at the prompt can be executed trough the subshell. If you want me to 
go into details - I'll do.

> >    * execution of commands typed at MC's prompt widget trough the
> >      subshell
> read my lips: NO WAY IN HELL. ;)
> this is one of the few actual selling points of mc over all the other

The prompt widget or the fact that if the subshell is enabled commands
are executed trough the subshell ? Don't get me wrong - I want to keep
the prompt widget. What I propose is to handle commands typed at it
just as if the subshell is disabled. I cannot see how commands typed
at the prompt and executed trough the subshell give MC an advantage
over the other file managers. Could you elaborate ?

> nice file managers. it's just a pity that it does not work in the other
> direction as well. the only problem i have is mc permanently
> mis-detecting that the shell is busy, but that is worked around by
> "ctrl-o enter ctrl-o alt-p enter".

The problem that I was debugging - it was related to this feature. In 
short:

1) Start MC

2) Type a command that will take some time to execute at  MC's prompt:
   for example - ls -lR /

3) While the command is running hit Enter

This causes the following problem:

1) The subshell remains stopped

2) The subshell prompt isn't retrieved properly

This happens on FreeBSD consistently but it could happen
on other systems too. It is caused by the fact that before the
command execution completes the newline character gets to the
subshell and  it is interpreted normally. This causes two things - first 
the subshell remains stopped because MC doesn't revive it after the 
subshell SIGSTOPs itself, and second the prompt gets mixed with the 
newline character which in turn causes the code which reads the prompt to 
misbehave.

I can explain in further details if it doesn't become very clear (i am a 
bit tired right now).

Thinking about a solution for this problem I realized that there is
no way to solve this unless MC could read peoples (the
subshell behaviour in this case lacks clear definition). Even if it had
I am sure that there would be a group of people who wouldn't be satisfied. 
The problem described is the result of lack of clear definition of MC's
behaviour in this case, different implementations of pty's on different 
OSes, bad interaction between features and (maybe) programming errors. 
It's just too complicated. I want to get rid of this complicated behaviour 
- I have debugged many of the subshell problems and I really want to put
and end to it.