mc's weird condition...

[Reynir Stefansson <reynirhs mi is>]

Now that the existence of this condition has been thoroughly verified on
my system (if no-one else's), here are some notes.

The version of mc in use is 4.6.1 with the 2007-03-09-18 patch. I think
I've observed it before that. I just didn't think any of it.

1. Only the Open action is affected. Typed-in commands are immune.

2. In initial condition, certain programs' output begins to disappear.

3. In advanced condition, those same programs may abort (on an SSH
console) or hang (on *the* console).

A possible way to nring out this behaviour is to:
    a. Keep an instance of MC running continuously for days or weeks.
    b. On other log-ins, run MC for shorter periods at a time.
    c. On all instances, play a lot with files - listen to music,
preview MIDI files, look at your GIF collection, read stories, read
manuals - just do a lot of it. The condition sneaks up slowly, so it's
probably a corruption issue.
    d. Programs I've observed to suffer with this condition are: oggenc,
ogg123, mpg321, adplay, sidplay2 and joe. Makefiles, if GCC outputs a
warning or error. Shell scripts, if there's an error. IIRC, lame feels
it, too.

My login shell is bash 2.05b.0(1)-release. My /bin/sh, however, has
hitherto been ash 0.4.0, compiled statically with dietlibc. I've used
that because it needs just 128K of memory. Right now, it's ash 0.4.0
dynalinked against glibc. I intend to see if that affects the issue. If
not, I'll make bash my /bin/sh and try again. Once this cycle is
through, it's time for the 4.6.2 candidate.

Since my system is based on LFS/BLFS 5, a look at linuxfromscratch.org
may help some. They do not use dietlibc, though. Shame, because it's so
useful for daemons and various utils you want to be able to use, even in
the unlikely incident of glibc going splat.

Reynir H. Stefansson (reynirhs mi is)
--
There is only one BIG problem with Microsoft: They want to 0WN3R us.