On Fri, 25 Oct 2019 at 20:14, Kenneth Porter shiva@sewingwitch.com wrote:
Found it. It happens from the process buffer inside Lugaru Epsilon. I think ls thinks it's doing a DIRED output instead of a shell output. Now I need to figure out why it thinks that. This wasn't happening in CentOS 7.
Lugaru Epsilon? I think you need to give a lot more explanation on what is going on because I (at least) have no idea how you are using a non-shipped text editor .
Usually if a tool is not giving similar results... I usually start by setting up a new account and unset all SHELL variables in said account. I then see if the problem occurs. If it doesn't, I make changes one by one from the other shells variables to see if it does. [Well I probably do the Wise Old Owl from the tootsy pop commercial.. once I hit three I start moving files until I get it.. sometimes it turns out that it is some weird config setting I didn't know in a file I didn't think would affect things.]
I am going to expect that TERM=DUMB might be the problem.. but not sure.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
It's not a ls bug. I've stepped through the code with gdb and it looks just fine. At this point I think Epsilon (a 32-bit app) is corrupting the image of its child process in a strange way. I'm working with the author at Lugaru (who's very responsive) to track it down. He couldn't reproduce it right away. I just reproduced it on a virgin CentOS 8 image at Linode with utterly no modifications. I just spun up the VM, logged in, scp'd the Epsilon RPM, dnf installed it, and demonstrated the issue.
I extracted the formatting code from the ls source to create a short test program that doesn't rely on anything external like a file's actual modes. It's just the code that builds the string from the mode word. It looks like it mysteriously skips the middle of the routine for no reason when spawned either as a grandchild through bash or directly via whatever Epsilon uses to spawn a child process.
It's definitely a spooky Halloween bug!
It's a display bug in PuTTY+Epsilon, but a subtle one! I upgraded PuTTY from 0.65 on one PC to 0.73 (latest) and the problem disappeared. I still see it on another PC running PuTTY 0.70.
I'm still trying to characterize it but the output is correct and it's because I'm using Epsilon to view the output file that I'm not seeing the missing characters.
The issue is related to repeating characters, such as the runs of dashes seen in a ls listing. But I'm able to reproduce it by displaying a file with a run of any character in Epsilon. So there's some quirky interaction between the terminal usage of Epsilon, PuTTY 0.70, and CentOS 8's openssh+bash.
I ran back through PuTTY versions and it doesn't happen starting with 0.71, so that version fixed something that CentOS 8 triggers in the older versions. Here's its changelog:
https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
It's a missing ncurses feature in the older PuTTY that's trigged by an update to ncurses or terminfo in CentOS 8. PuTTY 0.72 added support for the REP (repeating character) command and the newer terminfo adds that as an xterm feature. The Epsilon author spotted it in the PuTTY changelog.
So any curses app that uses repeating characters will have this problem when used with an old PuTTY version.
Here's an example of someone running into this with iptraf-ng on Arch Linux a couple years ago:
On Sun, 27 Oct 2019 08:25:28 -0700 Kenneth Porter shiva@sewingwitch.com wrote:
It's a missing ncurses feature in the older PuTTY that's trigged by an update to ncurses or terminfo in CentOS 8. PuTTY 0.72 added support for the REP (repeating character) command and the newer terminfo adds that as an xterm feature. The Epsilon author spotted it in the PuTTY changelog.
So any curses app that uses repeating characters will have this problem when used with an old PuTTY version.
Nice trouble shooting. It's always satisfying to get to the root of things.
Cheers, Peter
-
Kenneth Porter -
Peter Kjellström -
Stephen John Smoogen