Mark Millard wrote: > > > On 2020-Jul-10, at 16:12, Yuri Pankov <yuripv at yuripv.dev> wrote: > >> Mark Millard wrote: >>> On 2020-Jul-10, at 11:05, Yuri Pankov <yuripv at yuripv.dev> wrote: >>>> Steve Wills wrote: >>>>> On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: >>>>>>> Author: daichi >>>>>>> Date: Fri Sep 20 17:37:23 2019 >>>>>>> New Revision: 352558 >>>>>>> URL: >>>>>>> https://svnweb.freebsd.org/changeset/base/352558 >>>>>>> >>>>>>> >>>>>>> Log: >>>>>>> top(1): support multibyte characters in command names (ARGV array) >>>>>>> depending on locale. >>>>>>> - add setlocale() >>>>>>> - remove printable() function >>>>>>> - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display >>>>>>> non-printable characters that do not use C-style backslash sequences >>>>>>> in three digit octal sequence, or remove it >>>>>>> This change allows multibyte characters to be displayed according to >>>>>>> locale. If it is recognized as a non-display character according to the >>>>>>> locale, it is displayed in three digit octal sequence. >>>>>>> >>>>>> >>>>>> Initially picking on tab characters as an example of what is >>>>>> probably a somewhat broader issue . . . >>>>>> >>>>>> Ever since this change, characters like tabs that do not fit >>>>>> in the next character cell when output, but for which they >>>>>> are !isprintable(...), now mess up the top display. Again >>>>>> using tab as an example: line wrapping from the text having >>>>>> been shifted over by more than one character cell. top does >>>>>> not track the line wrapping result in how it decides what >>>>>> to output for the following display updates. >>>>>> >>>>> Apologies for the way late reply here, but I just now bothered tracking this down. This commit seems to be the cause of some corruption I'm seeing in long running top(1) as well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla bug? I can share screenshots of the corruption, such as: >>>>> https://i.imgur.com/Xqlwf9h.png >>>>> https://i.imgur.com/Jv0d5NU.png >>>> >>>> Does removing VIS_SAFE fixes the issue for you? >>>> >>>> As for original Mark's report (which I missed), removing isprintable() doesn't look wrong as vis(3) should take of its functionality (and in multibyte-aware way). >>> vis (as used) and the old isprintable logic are not >>> equivalent when multi-byte is not needed/involved. >>> Otherwise I'd not have had anything to ever report. >>> If vis can do what is needed, more work needed to >>> be done when the change was made in order to avoid >>> msesed up displays in single-byte contexts. >>>> Also, is there an easy way to reproduce this? >>> The following sort of command (the empty space inside quoted >>> text are tab characters): >>> # tr '0\n 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > /dev/null >>> causes my 200 character wide window running top to show: >>> 32920 root 100 0 12764Ki 2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n 2\\n 3\\n 4\\n 5\\n 6\\n 7\\n 8\\n \\t0 \\t1 \\t2 \\t3 \\t4 \\t5 \\t6 \\t733 \\t8 20 7172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid >>> But that does not show where the lines wrap at the edges of the window, >>> so breaking it up explicitly after the first "\" in \\7: >>> 32920 root 100 0 12764Ki 2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n 2\\n 3\\n 4\\n 5\\n 6\\n 7\\n 8\\n \\t0 \\t1 \\t2 \\t3 \\t4 \\t5 \\t6 \ >>> \t733 \\t8 20 7172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid >>> Note how \n turned into \\n , taking an extra character for >>> each \n . Similarly for \t vs. \\t . (Other examples do >>> similarly.) >>> The tab characters really do use more than one character cell >>> on the display (sometimes). >>> The text from the tr command ends up spread across 2 lines >>> as things look like in the window where top is running. >>> I ran top in another ssh session first and then the tr command. >>> Before running the tr command, top showed as: >>> 33019 root 20 0 17172Ki 5448Ki CPU24 24 0:00 0.05% top -HiSCazopid >>> If you do not end up with top listed just after tr in top's output, >>> then it will not be top's line that ends up partially overwritten. >>> If you have wider windows, you may need more text in the tr quoted >>> strings. >>> In another experiment I inserted a large number of backspace characters >>> (control-H's) at the front of the first quoted string in the tr command. >>> The top output displayed: >>> 0\\n5 ro1\\n 2\\93 3\\n12764\\n 25\\ni CP6\\n 97\\n:12 100.00\t0r \nHiS\\t1pid \\t2 \\t3 \\t4 \\t5 \\t6 \\t >>> 33094 root 20 0 17172Ki 5488Ki CPU21 21 0:00 0.06% top -HiSCazopid >>> In other words, backspace moved the cursor position back over prior >>> fields on the line and then the later line content overwrote those >>> fields instead of being after "tr" someplace (or truncated off). >>> Note that part of "-HiSCazopid" shows up on both lines. The extra >>> is from when top was running but tr had not started yet. top is >>> not managing text replacement correctly for output characters that >>> end up not being just "in" the next character-cell on the terminal. >>> The same sort of result happens when instead adding just one >>> carriage return (control-M) in front of that first quuoted >>> string instead: >>> 0\\n8 ro1\\n 2\\92 3\\n12764\\n 25\\ni CP6\\n 117\\n:11 100.00\t0r \nHiS\\t1pid \\t2 \\t3 \\t4 \\t5 \\t6 \\t >>> 33094 root 20 0 17172Ki 5488Ki CPU23 23 0:00 0.04% top -HiSCazopid >>> I do not intend to try to find all examples of characters that >>> cause problems but used to not cause problems. >>> From what I've seen, cursor positioning escape character sequences >>> seem to be sent through and cause overwrites at arbitrary places >>> on screen, based on the escape sequence content. There are command >>> lines around that contain such sequences. So I sometimes see the >>> first few lines of top's output have garbage text from commands >>> that were listed below at some point overwriting the top text. >>> Part of what is going on is top avoiding rewriting characters >>> that its tracking indicates have not been updated. When the >>> actual display and that supposed-tracking mismatch, the >>> display ends up wrong when updated (bad text continues to >>> display). >>> The text in commands should not make "top -a" output mess up >>> the display of other lines in top's output, nor of other >>> top output fields on the same line. In my view, if some usage >>> contexts need otherwise, it should take an extra command line >>> option to put top in a mode that might do such things. The >>> default behavior should strictly avoid having such things >>> happen. >> >> Thanks. >> >> The attached diff seems to take care of the issue for me, adding VIS_TAB and removing VIS_SAFE, which can be blamed for passing through the following: >> >> VIS_SAFE Currently this form allows space, tab, newline, backspace, >> bell, and return — in addition to all graphic characters — >> unencoded. >> <top.txt> > > A quick test suggests agreement. We will see how it > looks for on-going use. > > But I'll note that top's man page should document the > translations that are being used: it is not the same > text that top produced before -r352558 and one should > be able to read the man page to find out how to > interpret what top reports for the likes of top -a . I think this was taken care of in r352568, and what it says now is correct: Non-printable characters in the command line are encoded in C-style backslash sequences or a three digit octal sequences. > (It does not appear that escape sequences or vertical > tab would have gone through unencoded. So I'm still > unclear how I ever had the top few lines of top's > output messed up by command text. So it is also > unclear that this change would make a difference > for such. We will see over time if that text is > ever messed up.)Received on Fri Jul 10 2020 - 22:48:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC
