On Sat, Jan 18, 2020 at 12:26:34AM +0100, Vincent Lefevre wrote: > On 2020-01-18 00:02:46 +0100, Vincent Lefevre wrote: > > On my machine, the problem is almost always reproducible with > > > > ll -R /run | less > > > > where > > > > zira:~> where ll > > ll: aliased to ls -l > > zira:~> where ls > > ls: aliased to \ls -bFv --color > > /bin/ls > > > > but it does not seem to be reproducible with > > > > /bin/ls -bFv --color -l -R /run | less > > > > That's rather strange. > > The xterm logs show that stdout and stderr are mixed up in different > ways, which explains that the bug does not occur with the second > command. In short, there's some kind of race condition, and I suppose > that the difference is caused by a slightly different timing between > both commands. This *might* also explain why I cannot reproduce the > bug in other terminals. There's nothing for me to fix: + xterm's checking for invalid escape sequences, and stopping interpretation when it sees an error. Some other terminal can check and handle the error differently (or in the examples you gave, simply not check at all). Because xterm's using a state machine, it'll see errors that a switch/case logic won't address. In this report, you've assumed that terminals respond to errors identically. + there's no way that xterm can ever tell which bits came from your stdout and which from stderr. In this report you've assumed that it can. + for issues such as this, using "script" to generate a typescript file is the place to start (providing a reproducible test-case). You've described an error condition which you cannot reproduce at will. You really ought to read the tag descriptions: https://www.debian.org/Bugs/Developer#tags -- Thomas E. Dickey <dickey@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net
Attachment:
signature.asc
Description: PGP signature