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. _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel