Add support for a global /etc/lessignore file in addition to ${HOME}/.lessignore - #209
Conversation
less supports calling LESSOPEN with a double pipe since v447, like LESSOPEN='||/usr/bin/lesspipe.sh %s'. When using it this way, less can differentiate between a lesspipe that returns an actually empty file and the case when lesspipe doesn't want to interfere and tells less to directly open the file by using a non-zero returncode. This allows for example to use the follow (+F) mode. Before this patch lesspipe.sh already had partial support for the double pipe call. This is done by detecting the double pipe call and setting $retval. But this mechanism wasn't used for .lessignore and when less was called with "+F". This patch extends support for those codepaths too.
….lessignore
The ${HOME}/.lessignore has precedence and if it exists, /etc/lessignore is not
used. This prevents any kind mixing of the two files.
Having a global /etc/lessignore makes it easy to distribute a common setup that
excludes things like /var/log/syslog, /var/log/messages and the like per default,
while still allowing user overrides.
|
Thanks for the patches. While in the README there is a recipe how to work with growing files, it is somehow complicated and I got already complaints to revert to the old behavior. The remedy would be to no longer pass plain text files through a colorizer. Maybe your patches are nevertheless useful and I leave the lessignore functionality. But this means, I need to look carefully and do testing on several platforms. That will happen hopefully during the next few weeks, when I do have access to all platforms again. |
|
Thanks for your quick reply. As you might guess I'm a heavy user of the less follow mode, while still wanting to enjoy the comfort of lesspipe. I got one more idea how to automatically detect logfiles where you want to use the follow mode. I'm currently playing with this and will probably send another pull request soon. Since all my patches touch similar areas of the code, I unfortunately have them to base on top of each other to prevent merge conflicts. So feel free to just pick the parts you want or tell me how you would like to have them arranged and I will reorder them or similar. I have no problem waiting until you have time to test all the different platforms. |
|
The other idea I had turned out to not be reliable enough. So no more pull request in development from me right now.
If you care about my opinion on that: I don't need a plaintext colorizer, but I use follow mode with growing files all the time. So I would prefer if you either revert to the old behavior without colorizer for plaintext where follow mode directly works, or at least apply my patches that make it easier to turn off colorizing for the files where it gets in the way. I want it to do "the right thing" automatically, having to specify "+F" on the commandline all the time and not being able to just invoke F when less is already running would be annoying, because I very often switch between analyzing old data and the things that are written right now with follow mode. |
2 participants
The ${HOME}/.lessignore has precedence and if it exists, /etc/lessignore is not
used. This prevents any kind mixing of the two files.
Having a global /etc/lessignore makes it easy to distribute a common setup that
excludes things like /var/log/syslog, /var/log/messages and the like per default,
while still allowing user overrides.
Apply this pull request after #208
to prevent conflicts.