Steps to reproduce on macOS 14.6.1:
- Install less from Git (or v661 from Homebrew, both will reproduce this).
- Make an executable filter shell script
/tmp/testfilter that just does echo '😁'. I don't quite understand whether it's important that the first byte of output be greater than 0x7f or not, but I'm using that for my test case because that's what my real LESSFILTER setting ends up outputting as its first byte.
env - LANG=en_US.UTF-8 LESS=-RF TERM=ansi LESSOPEN='|/tmp/testfilter %s' less /etc/passwd
Expected results: 😁
Actual results: <9F><98><81>; the initial
I did a git bisect and came up with 2d0abe8 as the first commit where this happens. The prior commit, 0c39562, does not exhibit this problem. I tried to figure out what might be causing this in that commit, but I can't see it.
#498 has a suspiciously familiar description, but seeing as it's talking about v644—and it's closed—it's very possibly unrelated. I wanted to mention it just in case.
I cannot reproduce this in an Ubuntu VM with less built from sources. I have been able to reproduce it on two macOS systems.
Note that my actual use case is with bat using something like LESSFILTER='|bat --color always %s'. I noticed this because bat is trying to do some fancy line art, and it's always corrupted at the beginning because the first 0xe2 byte in its output is being removed. My actual TERM=screen-256color in tmux, using iTerm2; but I was able to reproduce this on macOS's included Terminal.app outside of tmux with TERM=xterm-256color as well. My macOS systems both use Homebrew for installing bat, less, and other dependencies.
This version of macOS ships less v581.2, which does not exhibit this problem.
Thank you for less! I remember the bad old days, when I had to get on a system without less and everything sucked more. :) (Now I just have the bad days where I shell into a container that doesn't have less...)
Steps to reproduce on macOS 14.6.1:
/tmp/testfilterthat just doesecho '😁'. I don't quite understand whether it's important that the first byte of output be greater than 0x7f or not, but I'm using that for my test case because that's what my realLESSFILTERsetting ends up outputting as its first byte.env - LANG=en_US.UTF-8 LESS=-RF TERM=ansi LESSOPEN='|/tmp/testfilter %s' less /etc/passwdExpected results: 😁
Actual results:
<9F><98><81>; the initialI did a
git bisectand came up with 2d0abe8 as the first commit where this happens. The prior commit, 0c39562, does not exhibit this problem. I tried to figure out what might be causing this in that commit, but I can't see it.#498 has a suspiciously familiar description, but seeing as it's talking about v644—and it's closed—it's very possibly unrelated. I wanted to mention it just in case.
I cannot reproduce this in an Ubuntu VM with less built from sources. I have been able to reproduce it on two macOS systems.
Note that my actual use case is with bat using something like
LESSFILTER='|bat --color always %s'. I noticed this because bat is trying to do some fancy line art, and it's always corrupted at the beginning because the first 0xe2 byte in its output is being removed. My actualTERM=screen-256colorin tmux, using iTerm2; but I was able to reproduce this on macOS's included Terminal.app outside of tmux withTERM=xterm-256coloras well. My macOS systems both use Homebrew for installing bat, less, and other dependencies.This version of macOS ships less v581.2, which does not exhibit this problem.
Thank you for less! I remember the bad old days, when I had to get on a system without less and everything sucked more. :) (Now I just have the bad days where I shell into a container that doesn't have less...)