After an update I noticed that my bash profile for man colorization breaks paging. I don't know what changed but I narrowed it down to the fact that calling env less hello.txt results in contents of hello.txt being echoed to the terminal (like cat) without the paging behavior. How do I debug and fix this?

To eliminate the effect of some environment variables, I tested with the minimal environment:

env -i TERM=xterm-256color /usr/bin/less hello.txt

or even:

env -i /usr/bin/less hello.txt

This also simply prints the file to stdout. On a different machine with the same software versions, the paging works (if TERM is preserved).

Since even env -i behaves differently, I don't suppose that the reason is something in my environment.

Versions of less and env are the same: less 581.2 (PCRE2 regular expressions) and GNU coreutils 8.32, OS is Arch Linux 64 bit, up to date, shell: GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu).

  • 1
    Is less an alias or function? What does type less; type env output? Commented May 13, 2021 at 15:08
  • Goddammit... I typed out the full path to less to be sure, but I didn't think of env. If I do /usr/bin/env instead, it works. The alias comes from the same grc package: env is aliased to 'colourify env'. Commented May 13, 2021 at 15:12
  • 1
    Wow, I would file a bug against this package. env is a simple tool with a simple job and messing with it is bound to create this kind of weird problem. Commented May 13, 2021 at 15:14
  • colourify is in turn aliased to grc -es, where -es means that it redirects the stdout and stderr of invoked commands. Not sure how the redirection is used, but I guess less detects it and changes behavior accordingly. Commented May 13, 2021 at 15:16
  • less behaves like cat when its output is not a terminal, so that you can have a program (such as man) automatically pipe to less, but still pipe its output if you want. Commented May 13, 2021 at 15:19

1 Answer 1


The most likely explanation for env foo … behaving differently from a plain foo … is that foo is a function or alias. Since env is an external command, it looks up foo as an external command.

Here, though, env itself turned out to be an alias. Obviously, if env isn't the standard env command, it might behave differently.

this turned out to be a bug in grc which sets up a file included during the bash startup (there are zsh and fish versions as well) which defines many commands, including env, as aliases: env is aliased to grc -es env. grc -es … runs the specified command with its standard output and standard error both redirected to a pipe in which grc inserts escape sequences to change the text color. This is fine for commands that produce output that humans want to read in a nicely formatted way. But it doesn't make sense to do it for env, which is a command whose primary role is to invoke another command with a modified environment. Automatically redirecting the output and error output of foo to a pipe when the user runs env foo is disruptive, and it's useless anyway since grc doesn't know how to colorize the output. I guess the goal was to colorize the output of env with no arguments, which displays the environment, but this is pretty useless since the output of env is not very user-friendly in the first place: export does a better job, as unlike env it produces sorted output (and quoted in a form that makes values with newlines unambiguous).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .