Hi all,
Please forgive me if you saw this post in other forums as well. I just do not seem to get any answer....

A. My Environment
==============
I am using RedHat Linux, version 2.6.18-53.el5.
When I type less --version I get:

less 394
Copyright © 1984-2005 Mark Nudelman
...

My terminal is configured as Xterm, using ANSI colors and indeed, typing
ls --color=yes produces a colored list.

B. Background
===========
I am using a small pearl script that colors lines of text according to predefined key words.
This is a very nice utility. When I redirect tail -f output to it, it produces nice color logs of my server, with words such as "Exception" or "Error" conveniently colored.

Recently I wanted to try a more ambitious use of this script: To use it together with less command.

Anyone can understand, that less +F is better than tail -f, as one can press CTRL+C at any given time when viewing a file online, and scroll or search within it effortlessly, without ever returning to the shell prompt.

Which leads me to:

C. The Problem
===========
1. I can not get less to show color.
Even typing "ls --color=yes > test.txt"
and then less -r text.txt or less -R text.txt NEVER displays the content in color. The output is actually the same as doing a "ls --color=no"

2. I read a bit about less input preprocessor the related Environment Variables in UNIX man pages : less ().

3.But, I can not figure out how I can turn less to use colors on a regular basis, How I can make less to "relay" all its output through my color pearl script, and mostly - Is it possible at all?

Any help would be highly appreciated.

Attached are my and colorlogs.conf files, to complement this post.

Thank you in advance.

Dani AI

Generated

Nice work — your pipe-and-view approach proves the basic idea: less can show ANSI color sequences but only if those sequences actually exist in the stream/file and less is told not to strip them. The missing piece most people hit first is that many color-producing programs (and GNU utilities) only emit SGR/ANSI escapes when their stdout is a terminal. Redirecting output to a file or pipe therefore often strips the colors unless you force the program to always emit escape codes.

A robust, repeatable pattern that avoids writing a permanent intermediate file is to use a named pipe (FIFO) and ensure the colorizer runs line-buffered so escapes arrive in real time. Example workflow:

mkfifo /tmp/logfifo
tail -F /var/log/Server.log | stdbuf -oL ./your-colorizer.pl > /tmp/logfifo &
LESS=-R less /tmp/logfifo

This keeps the colorizer and viewer decoupled, lets less render SGR escapes safely (the LESS env or the -R option), and allows follow-like behavior inside less.

Troubleshooting tips and gotchas:

  • If colors still don’t appear, confirm the stream actually contains ANSI SGR escapes (search for ESC+[ with e.g. grep -P '\x1b\[' filename or inspect with od -c).
  • Some colorizers buffer output; for Perl add $| = 1; near the top or wrap with stdbuf -oL/unbuffer.
  • Prefer the “always” mode of GNU tools (so escape sequences are written even to files) rather than the default “auto” behavior.
  • Use -R (not -r) with less because it passes through SGR color codes safely without exposing other control sequences.
  • Clean up background jobs and remove the FIFO when done.

Alternatives: dedicated log colorizers (ccze, grc) or piping straight into less (with line-buffering) are simpler for ad-hoc checks. The FIFO approach is best for continuous, real-time viewing while keeping the workflow stable.

OK. At last, success.
This is the only thing that is working, 100% to my satisfaction.

nohup less +F /var/log/Server.log | /usr/local/src/Colorlogs/ > takethis.log &

less +F -f -R takethis.log

This works wonderfully.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.