Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 262222 - sys-apps/less: lesspipe.sh fails to correctly check $LESS
Summary: sys-apps/less: lesspipe.sh fails to correctly check $LESS
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-12 00:00 UTC by James Cloos
Modified: 2009-03-13 18:09 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Cloos 2009-03-12 00:00:33 UTC
The lesspipe.sh script in sys-apps/less/files contains code to colourize the viewed files; this code forces the colourization if $LESSCOLOR=always; that part works well.  As do the cases where $LESSCOLOR is unset, no, false or 0 (zero).

When $LESSCOLOR=yes, true or 1 (one), the code tries to check $LESS for the r or R flags, colourizing only if one of those two is set.  But the check only works if $LESS is of the form '-s -e -i -M -R' rather than the more common '-seiMR' style.

The check for -r or -R in $LESS needs to use case rather than == and needs to look for something like -*r*) and -*R*).

something like:

                for opt in ${LESS} ; do
                        case ${opt} in -*r* | -*R* )
                                ${LESSCOLORIZER} "$1"
                                break
                                ;;
                        esac
                done
Comment 1 SpanKY gentoo-dev 2009-03-12 22:44:42 UTC
that can lead to false positives.  set LESSCOLOR manually in your case.
Comment 2 James Cloos 2009-03-13 17:11:24 UTC
If it won’t be fixed then the buggy check should just be removed.

As it is, the common case is broken just to deal with uncommon cases.

As for:

> set LESSCOLOR manually in your case

this is only ever relevant when LESSCOLOR *is* manually set....
Comment 3 SpanKY gentoo-dev 2009-03-13 18:09:17 UTC
that may be your opinion, but it isnt mine

the existing check is not buggy, it just does not give 100% coverage.  i would rather have 85% coverage with no false positives than 100% coverage with false positives.