Re: a few small problems

[Glenn McKechnie <graybeard optusnet com au>]

bulia byak wrote:
> Here's an even simpler way to trigger this bug. In an empty command
> prompt, with panels off, press right-arrow. Nothing visibly changes,
> but apparently this causes the shell to enter into some sort of
> "command line editing" mode which in turn causes mc to lose connection
> with the shell. So if you now return the panels, the prompt is frozen
> and you cannot leave the current dir (you can go anywhere in the
> panel, but the current dir remains the same, and you are returned to
> it as soon as you run any command or switch off the panels).
>
> Please help me investigate if this is the bug in mc or in the shell,
> and what is the best way to fix it or at least to work around.  --

The bug is confirmed here by repeating the above steps.

To reproduce:

 1 Start mc
 2 Ctrl-o to get a subshell
 3 Use the right cursor key ( any key? ) at the subshell's command
 prompt.
 4 Ctrl-o back to mc
 5 type pwd at mc's command prompt and press enter
 6 Error message "The shell is already running a command" will appear

Expected behaviour:

 1-5 as above
 6 pwd command runs as usual (displays the working directory)


A side effect of the above behaviour?:

 1-4 as above
 5 take note of the current working directory
 6 within mc recurse any available directory
 7 take note of the new current working directory
 8 Ctrl-o to a subshell
 9 enter pwd at the command line and press enter, the path given will be
 that of the original at step 5.
 10 Ctrl-o back to mc
 11 mc's working directory will have reverted to step 5.
 
Expected behaviour:

 1-8 as above
 9 enter pwd at the command line and press enter, the path should be
 the same as step 7.
 10 Ctrl-o back to mc
 11 mc's working directory will be as in step 7.

Versions:

Tested with the following two versions on separate linux installations.
nodeges = Red Hat Linux release 8.0 (Psyche)
whitebeard = LFS build 3.3

[graybeard nodeges graybeard]$ mc -V
GNU Midnight Commander 4.5.55
Edition: text mode
Virtual File System: tarfs, extfs, ftpfs, mcfs, undelfs
With builtin Editor
Using system-installed S-Lang library with termcap database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
Using locale "C" (from environment variable LANG)

  graybeard whitebeard:~
  11:41am $mc -V
GNU Midnight Commander 4.6.0-pre2
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs
With builtin Editor
Using system-installed S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
  
Comments:

I believe this behaviour has been with mc for a while, as suggested by
the standard RedHat8.0 installation and the LFS build above. I recall it
in a RedHat6.2 GNU Midnight Commander 4.5.42 build as well.

I also thought it was due to the weird PS1 prompt I was using however
the results from the above two machines along with bulia's observations
shows that it is independent.

This is the first time I've seen a reproducible test for it, for which
I'm grateful. This test also allows the condition to be reset quickly,
For me though, it has often required restarting mc to regain normal
behaviour, no amount of pressing <enter> or Ctrl-o'ing has cleared it.

Solution:
I wish I had one. ;-)
However any keystroke entered on the subshell's prompt should be ignored
unless the enter key is pressed. Once the enter key executes a command
then the shell is truly busy and can gripe with that message "The shell
is already running a command". 
( Looking at that message: it isn't running a command, it's only preparing
to accept a command? which for unknown reasons wasn't completed. )

Could the act of switching with Ctrl-o clear the subshell's command line
( keyboard buffer? ) If we are switching with Ctrl-o it could be presumed
we are finished with the subshell's CLI entry ( not necessarily it's
displayed contents. )
FWIW, If I'm in the subshell and it's actively busy - eg: compiling,
then I don't expect to switch back to the mc display with Ctrl-o and
find mc usable. The emphasis being on "actively busy"...
 1. Switch to subshell using Ctrl-o
 2. type pwd in with no <Enter> key pressed
 3. Ctrl-o to mc ( mc sends reset or whatever to clear the pwd entry)
 4. enter ls AND press ENTER on mc's CL
 5. mc responds by executing the `ls` command.


Failing that, can mc process the command anyway...
 1. Switch to subshell using Ctrl-o
 2. type pwd in; with no <Enter> key pressed
 3. Ctrl-o to mc
 4. enter ls AND press ENTER on mc's CL
 5. mc responds with the shell error message of "bash: pwdls: command
 not found". 
This should then leave the CL ( either mc's or the subshell ) ready for
the next entry without all the Ctrl-o'ing and associated fluffing
around, trying to regain a valid state.

How this will affect the change directory problem I don't know, but that
behaviour is an even bigger pain in the royal butt, It's to be hoped
that it's directly related.


Having posted the above, I must take the opportunity to thank those who
code or otherwise participate in the development of MC. After Nautilus
arrived on the GNOME scene, its future didn't look too promising.

It's too useful to lose, even with its quirks. ;-)

-- 
Cheers
 Glenn

He who always plows a straight furrow is in a rut.