https://bugzilla.novell.com/show_bug.cgi?id=244791 judas_iscariote@shorewall.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org ------- Comment #1 from judas_iscariote@shorewall.net 2007-02-12 23:43 MST ------- test case needed, otherwise is hard to detect what error are you hitting... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791 judas_iscariote@shorewall.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791 mmarek@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org ------- Comment #2 from mmarek@novell.com 2007-02-13 00:13 MST ------- Yes, please attach 1) the file that less fails to show properly 2) exact less command line 3) output of 'printenv | grep LESS' -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791 suse@tlinx.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|suse@tlinx.org | ------- Comment #4 from suse@tlinx.org 2007-02-17 16:36 MST ------- invocation line: I attached a 20 line file I called "20_120char_lines.txt". My environment for LESS: LESSKEY=/etc/lesskey.bin LESSCHARSET=utf-8 LESS_ADVANCED_PREPROCESSOR=no LESS=-M -X -i -Rr LESSOPEN=lessopen.sh %s LESSCLOSE=lessclose.sh %s %s --- invocation line: less 20_120char_lines.txt ------- I changed my tty window size to rows=21, columns=80; if I run less with the "bad" version, it has a prompt that says: /tmp/20_120char_lines.txt lines 1-20/20 (END) indicating it has displayed all 20 lines of the file. Actually visible are only the last 10 lines. If I reinstall the previous version of less(394-12) from suse10.1, same command in same window now says: /tmp/20_120char_lines.txt lines 1-10/20 50% -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791 ------- Comment #6 from suse@tlinx.org 2007-02-19 14:00 MST ------- Sorry -- should have provided arguments. But it happened with any/every file, so that part didn't seem to matter. I vaguely remember something like this cropping up in the past -- someone decided to not keep track of any lines if "-r" was specified... If you are wanting anything to be displayed from "utf-8" (non-ascii), you need the "-r". I believe this may be a regression -- maybe someone made a mod from an old source? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791 ------- Comment #8 from anosek@novell.com 2007-06-05 02:38 MST ------- Response from Mark Nudelman (author of less): Hi, Unless I'm misunderstanding something, this behavior is documented in the man page: Warning: when the -r option is used, less cannot keep track of the actual appearance of the screen (since this depends on how the screen responds to each type of control character). Thus, various dis- play problems may result, such as long lines being split in the wrong place. Also see the FAQ entry http://www.greenwoodsoftware.com/less/faq.html#dashr Let me know if these items do not address the bug reported. --Mark -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791 ------- Comment #10 from anosek@novell.com 2007-06-05 02:56 MST ------- (In reply to comment #8)

Response from Mark Nudelman (author of less):

Mark, thank you for the answer. I added a new attachment based on previous 20_120char_lines.txt file. I numbered the lines. I you try to view this file with 'less -r 20_120char_lines.txt' and smaller xterm window (so that the lines wrap) you will only see lines 11-20. The first ten lines are cut off. Is this the correct behaviour? File 20_120char_lines.txt contains no other control characters than EOL. Thank you -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=244791#c12 L. A. Walsh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #12 from L. A. Walsh 2007-07-30 01:18:25 MST --- The -r flag is not inherently unreliable. It had a well defined behavior. It turned off obfuscation of non-printing ascii characters. It kept track of position just fine when normal characters were used. This was deterministic -- not unreliable. Extra code to disable position tracking had to be added to break this. It's not invalid to ask that previously working functionality be restored to its previous state. Either that, or add a new switch --no-obfuscate that won't print out question-marks or substitute characters, but will otherwise act the same in trying to keep the position and place. It may be unreliable to you -- but it worked reliable on regular ascii files. Why break it? If the author is unable to fix it, I can send a patch to restore it to the previous version -- but that seems ridiculous. Why add extra code to disable what was working? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=244791#c14 --- Comment #14 from L. A. Walsh 2007-08-02 23:46:26 MST --- Created an attachment (id=155348) --> (https://bugzilla.novell.com/attachment.cgi?id=155348) patch to less-dist to not throw away screen positioning -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=244791#c16 L. A. Walsh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED Info Provider|suse@tlinx.org | --- Comment #16 from L. A. Walsh 2007-08-02 23:49:22 MST --- I am not able to reproduce the original behavior/difference. I don't know why, but the upgrade to 10.2 "erased" the previously working behavior. I thought I tested 10.1 and it worked, but as you mention, the packages between 10.1 and 10.2 are the same. Either I had an unknown version of less installed, or (as you noted above), I changed the order of the LESS options. (from -rR to -Rr) The program (less) overloads 1 variable to hold the state of "r-off", "-r" or "-R". While it isn't stated, only the last "r" switch (-r or -R) takes effect. I'm guessing, but this behavior must have resulted in the confusion, somehow. (They should be orthogonal options, from my point of view -- not different values of 1 common switch -- that's confusing, but ...whatever...). I'm enclosing a patch to 2 files that fixes the problem -- sorta. Ideally, one could have both switches -- but I didn't separate them in this patch. Instead, I simply removed the 3 places in the code where "-r" throws away the line position information so its function will most closely match the man page. Manpage (as quoted above): when the -r option is used, less cannot keep track of the actual appearance of the screen ....various display problems may result, such as long lines being split in the wrong place. ------ As stated, the "-r" may cause long lines to be split "needlessly" (in wrong place), WITH the attached patch. As the code stands in 10.2, it conflicts with the manpage: a long line will never be split since it doesn't keep track of column information -- the only thing that will happen is that the line will wrap and less will scroll lines off the screen (as demonstrated with above test cases). I have a feeling "-r" used to be the way it is now (at least from reading the manpage), but the column tracking was removed. I.e. with column tracking enabled (and assuming no control characters reposition the cursor abnormally), the user may end up with lines split on screen too early and less may not make full use of the screen. With the code disabling column tracking entirely (as it is in 10.2), less will lose information off of the screen on long lines. I perceive the loss of information to be worse than "insufficiently optimized use of screen" (with no text lost). This patch does remove the ability to "ignore columns completely" -- which could have a use in viewing raw screen dumps with positioning information in them. This is a useful function as well, but less is more designed to display text files -- not binary files. Ideally the ability to display raw characters could be uncoupled from screen position accounting. This would likely require another option. Then a user could specify "raw" display but keep ANSI-escape-code-position tracking (the -R option). Two files attached, one the patch to the source distribution file "less.c" to NOT disable column tracking, and a diff to the spec file (bumping version from 394-32 to 394-32a). This may "qualify" this as an "RFE" (Request for Enhancement)... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=244791#c18 Ales Nosek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED Summary|less broken from 394-12(10.1) to 394-32(10.2) |Incorrect behaviour of -r parameter (was less | |broken from 394-12(10.1) to 394-32(10.2)) --- Comment #18 from Ales Nosek 2007-08-17 02:43:28 MST --- Thank you for the patch and explanation. I put it into Factory, it'll be in openSUSE 10.3. I'm not going to update less in older releases, because this is minor problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.