| Summary: | sys-apps/less: lesspipe.sh fails to correctly check $LESS | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James Cloos <cloos> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
that can lead to false positives. set LESSCOLOR manually in your case. 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....
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. |
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