Comments on Make Less use a normal view instead of hexdump view
Parent
Make Less use a normal view instead of hexdump view
Less does not display data files normally, but if it were some sort of Xxd.
$ bash --norc
$ export LESS=
$ file -i /var/log/lastlog
/var/log/lastlog: application/octet-stream; charset=binary
$ less -EX /var/log/lastlog
00000000 a3 4c d2 60 74 74 79 32 00 00 00 00 00 00 00 00 |.L.`tty2........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000474a0 ee c7 66 61 74 74 79 31 00 00 00 00 00 00 00 00 |..fatty1........|
000474b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000475c0 00 00 00 00 |....|
000475c4
Usually that is a good choice, but some data files are better read as normal text. How can I switch to the normal, plain text view in Less?
I have searched for "binary", "hex" and "xxd" in Less' manual but there does not seem to be a mention of it.
An update just to situate Canina's correct answer.
$ env | grep LESS
LESS=-iRj4
LESSOPEN=|lesspipe %s
lesspipe is a shell script with # Copyright 1999-2020 Gentoo Authors, so it is no surprise that many could not reproduce what I described.
Post
As I noted in a comment thread, I don't get the same behavior as you do (nor do I recall ever seeing it on any system), which points toward something about your setup. Apparently in response to the question about your ~/.bashrc, you showed that you run this from a freshly started shell (bash --norc); however, there is a methodological error here, as that bash instance is going to inherit its environment from the shell from which it is started, just like any other application that is started from the shell.
All this, to me, suggests that something in the environment that less is running within causes it to behave differently.
The easiest thing to check is that there is no alias for less that includes extraneous parameters that could influence its behavior. which less will tell you where less is on disk, and type less will tell you what bash does with a bare less, in case for example it is an alias. Invoking an executable using a path will bypass an alias; for example, if you had an alias less that added some parameters, using the path from which less would invoke less without those parameters being passed to it. Apparently, you had no such alias or similar that would interfere.
Next, you showed that you reset $LESS, but less uses a number of environment variables to control its behavior. Those are listed in the man page under the "environment variables" heading, or you can take the crude, somewhat brute-force way of finding out which the likely candidates are by doing something like:
$ man less | tr ' ' $'\n' | grep ^LESS | sort --unique
and comparing the output of that to the output of
$ env | grep ^LESS
In your case, it appears that this revealed that the value of $LESSOPEN was problematic. This is significant because $LESSOPEN controls input preprocessing. The script it points to is also likely to be provided by either your OS distribution (possibly from upstream), or locally; this might help explain why the behavior you are seeing differs from that on my system.
(Also note its sibling, $LESSCLOSE, which controls the opposite half of the invoke/exit cycle. See the less(1) and lesspipe(1) man pages for more details.)
$LESSOPEN can be ignored by passing either -L or its long form --no-lessopen when invoking less.
2 comment threads