Re: Makeing the subshell reliable
- From: Pavel Tsekov <ptsekov gmx net>
- Cc: MC dev <mc-devel gnome org>
- Subject: Re: Makeing the subshell reliable
- Date: Tue, 18 Jul 2006 16:54:18 +0300 (EEST)
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 :(
] [Thread Prev