(Inspired by this brief thread, and the pre-beta status of Slackware 15.0.)

Enabling color in "less", on a system-wide basis, might be useful or practical for some users/sites. And maybe not.

For Bourne-type shells and zsh, LESS is set in /etc/profile to "-M". The C shell equivalent is in /etc/csh.login. This makes it a system-wide default, and of course users may override that in their personal shell startup scripts, via something like LESS="$LESS -R".

From the above thread, it would make sense to add -R to $LESS by default, in order to get "git log" to show colorization properly. But it might also result in someone asking "if 'git log | less' shows color correctly, why isn't 'dmesg | less' showing it too?" And that's perfectly valid; dmesg writes color codes to a terminal, but not to a pipe.

Yes, it's possible to edit /etc/profile et al., but what happens during an upgrade of Bash or Tcsh? It's up to the admin to remember "oh yeah, LESS was customized" and even if that was the only customization, it blocks a new profile/csh.login from getting installed. That new script might include a security fix. Installing the new script, with a customized $LESS, makes just one more customization that has to get carried over.

Am I over-thinking this? Of course I am. But I want to present some pro/con points.

Another reason I'm bringing up this question now, is that we're gearing up for the 15.0 release, and that's the best time to make such a tweak to default settings.

So, what are your thoughts out there? Would you like our BDFL to add automatic color-handling to "less"?

Side note to our BDFL: your ruling is final, and a pox on anyone who says otherwise.

IMO, No.

-R is a potential security vulnerability as it opens less up to some of the same issues that viewing a file with 'more' or 'cat' has. i.e. it makes it possible to hide malicious code in script/source files.

Probably not a good idea to enable it out of the box for this reason.

That said I use LESS=-MRFX here, but I do so knowing the implications.

1 members found this post helpful.

The /etc/profile file is supplied in the etc package. It comes in with a .new file. An administrator needs to handle such a file.
Exactly.
From 'man bash'
From 'man zshall'
So, perhaps a custom ~/.profile would meet your need without any changes to /etc/profile.

Oh, I am voting No.

1 members found this post helpful.

IMO, the only thing the stock /etc/profile should be doing is to ensure a sensible PATH and umask value, and then source the profile.d/ members. Any additional vendor customisations could then be placed in a profile.d/aaa_slackware.sh which could, if required, easily be disabled by the user with a good old chmod -x in the usual slackware fashion.

But, as allend says, it's easy enough to override things from the other shell init files, or just manage /etc/profile yourself. I've reworked both my etc/profile and xdm/Xsession into something a little nicer, so I'm used to dealing with it when Pat changes something in there.

I don't pay much attention to any of the *.csh in there as I never use that shell.

1 members found this post helpful.