Re: Makeing the subshell reliable

[Pavel Tsekov <ptsekov gmx net>]

On Sat, 15 Jul 2006, Oswald Buddenhagen wrote:

> > I am not advertising the removal of the subshell . I just want to remove
> > the ability to execute commands typed at MC's prompt widget trough the
> > subshell (if it isn't clear yet).
> good. but exactly this integration makes it so valuable for me.
> otherwise i could just use another xterm/vt/screen.

Ok. I got the point. This feature is just too important to be sacrifaced.

> > However, if this functionality is to remain we have to define exactly
> > how it is supposed to work and the subshell prompt should definitely
> > go. My opinion is that if we start to impose restrictions on that
> > feature there would alway be a group of confused users since it want
> > behave exactly as they would expect to. But I am open to suggestions.
> the current implementation is a mc command prompt and a real shell
> prompt. the mc prompt can inject commands into the shell. disadvantages
> are that it is strictly one-way and it seems to be somewhat whacky (but
> i must say, i'm obviously trained enough not to do the stupid things - i
> didn't have problems with it for ages).

I also don't remember having major trouble with the subshell myself but
then there are enough records in this mailing list and in other places
which testify that the subshell is causing a lot of confusion. A lot of
efforts were thrown in an attempt to solve the unsolvable "The shell is
already running a command" problem for example.

> the second variant would be embedding the real shell prompt into the
> panels. this could work by presenting the shell a really tiny pty. to

Could you elaborate, please ? Do you mean implementing another view for
the panels that will display the output of the subshell and will pass the
user input to the subshell ? In short the same behaviour that is currently
invoked by pressing Ctrl+O ? Shall we keep the prompt in this case ?

> personally i'd go with variant two (unless somebody points out a
> fundamental flaw in the idea (no, i'm not talking about implementation
> problems)). to even think about that, we need to get the current code
> working reliably. i'll investigate this myself - however, i won't make
> *any* promises about the time frame.

The current code would work well if:

1) It doesn't have to retrieve the prompt

2) The state of the subshell is not tracked. This could be
   improved but I don't think its worth the effort, IMO.

Btw I'd think it would be good to switch to a better way to
determine the subshell's current directory as well since the
current method reduces the number of the supported shells.
Reading /proc (if mounted) seems appropriate since it is
available on most of the popular platforms. Of course we could
fallback if proc is not available.

P.S. It's sad that not so many people joined the discussion :(