One way to reproduce:
- Open urxvt and make it 10 characters wide.
- echo 12345678 > foo.txt
- ack 1
This results in:
which, as you can see, is missing an 8! I say "one way to reproduce" above because some bits of the instructions are needlessly specific. You can use any pattern that matches the line in question, not just "1". Additionally, what really matters about the line being matched is that it be two characters shorter than the terminal's width -- so if you have a convenient way to open an 80-character wide terminal, for example, you could just write a file with a 78-character line. However, which terminal you use does seem to matter -- urxvt and xterm show this behavior, while gnome-terminal seems not to.
This issue was originally raised at https://groups.google.com/forum/#!topic/ack-users/SfZ7biJAEnU which spawned these additional comments:
Reproducible. On my Ubuntu LTS(12.04), i can reproduce with Xterm and Byobu terminal, with both Ubuntu/Debian ack-grep 1.92 (-a
flag required) and ack2 standalone 2.13_06 (installed as ~/bin/ack2), both under Perl 5.14, and confirm that Gnome terminal does not reproduce.
https://groups.google.com/group/ack-users/attach/2542904a22f873cb/image.png?part=5&authuser=0
Andy> What happens if you use grep instead of ack in your example? How about if you try ack --nocolor?
ack2 --nocolor
does indeed show the 8, as does ack1, confirming Andy's hypothesis.
grep -n 1 foo.txt
shows
1:12345678
colorized properly in 10 char Xterm.
https://groups.google.com/group/ack-users/attach/2542904a22f873cb/image.png?part=4&authuser=0
ack --color 1 | cat
exhibits the same truncation effect if Xterm is snugged to where the 8 will be
foo.txt:1:12345678<- put margin here
foo.txt:1:1234567
My tests on --pager='less -r'
are inconclusive; it doesn't help in Xterm, not sure what Byobu is doing.
Instructions could be "snug the terminal to hug the line:text return, redo command, observe space at end replacing last character". Should include "in a clean directory" of course, since you only want one file; or call by name, ack 1 foo.txt. Since Xterm is most ubiquitous, recommend that being the Terminal of record for this bug.
Workaround - if full line contents is important, don't use color.
Unknowns. What we don't know for sure is that we're not sending the 8. It could be we're sending the 8 but a bug in the Term emulation is eating it. Select full line does NOT copy an 8, so i suspect we can discount this being a XTERM display bug, but that's hardly certain.
TBD. Unclear if there's any way to reproduce this under Test::Harness control? Before attempting fix, an automated test that fails would be desirable. Do we need to find what ENV or TERMCAP or equiv elicits this bug ? ugh.
DX. Assuming it's us, it's a squirly off by one in the fit-buffer-to-TERM calc, influenced by different Term's ENV/TERMCAP/etc.
probably worth trying a 78 char line in 80 wide terminal on Windows and OS X too (unless they can do 10 char wide terminal which is convenient but ugly ! )`