Post History

As I noted [in a comment thread](/comments/thread/4822), 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`.**