|
Bugzilla – Full Text Bug Listing |
| Summary: | less: Confusing response to input "-i" | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Ulrich Windl <Ulrich.Windl> |
| Component: | Basesystem | Assignee: | Stanislav Brabec <sbrabec> |
| Status: | CONFIRMED --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | sbrabec, Ulrich.Windl |
| Version: | Leap 15.5 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Reporter, * Does this happen on 643 on Tumbleweed? * If no is this your issue? https://github.com/gwsw/less/issues/300 * If yes did you report this upstream? (In reply to Andreas Stieger from comment #1) > * Does this happen on 643 on Tumbleweed? Did not check, but originally found in SLES12 SP5. And I can remember that once this worked correctly, but I must admit that I use less for more than 20 years. > * If no is this your issue? https://github.com/gwsw/less/issues/300 That bug sounds like the opposite, somehow. Still it could have the same root cause. > * If yes did you report this upstream? No, because I don't know how heavily the less is patched compared to upstream. Please confirm whether this also occurs in the Tumbleweed version. A co-worker checked with Debian 12: There is less 590-2 that does not have this bug (SUSE is at 458 it seems). (In reply to Andreas Stieger from comment #3) > Please confirm whether this also occurs in the Tumbleweed version. I have no Thumbleweed here. 🤷 (In reply to Ulrich Windl from comment #4) > A co-worker checked with Debian 12: There is less 590-2 that does not have > this bug (SUSE is at 458 it seems). Leap 15.5 ships less-590. > No, because I don't know how heavily the less is patched compared to upstream. The package contains just 3 patches, one of which is a fix for a security issue and the other 2 don't seem related to this issue. Regarding the debian package, they also don't have any patch related to this issue, so it's really weird that it's happening only in Leap. Strange (the version thing). So I guessed it might be some special options passed when running less from man, and tried a direct approach using % less /usr/share/doc/release-notes/openSUSE/RELEASE-NOTES.en.txt In Leap 15.5 using less-590-150400.3.3.1.x86_64 and "Package" as search string, the issue is still there. Maybe it's the environment: % env | grep LESS LESSCLOSE=lessclose.sh %s %s LESS=-M -I -R LESS_ADVANCED_PREPROCESSOR=no LESSKEY=/etc/lesskey.bin LESSOPEN=lessopen.sh %s I have tested less on SLE-15-SP5 and when the search starts with an uppercase letter, than -i does not work correctly. Can you please confirm this is the issue you have as well? (In reply to Danilo Spinella from comment #9) > I have tested less on SLE-15-SP5 and when the search starts with an > uppercase letter, than -i does not work correctly. Can you please confirm > this is the issue you have as well? (I wrote in comment #0) > When starting less (e.g. via man) and searching, the search is > case-insensitive. Doesn't that answer the question? In SLES15 SP5 as root user I enteerd "man bash", then entered "/BASH", and highlighted words were "BASH", "bash", and "Bash". However "_i" reports "Ignore case in searches and in patterns" then. More importantly: After entering "-i" the first time, the status is still "Ignore case in searches", but when continuing the search by pressing "n", the matching is CASE SENSTITIVE then! Entering "-i" another time, lets less report "Case is significant in searches", and it actually IS. Entering "-i" again, lets less report "Ignore case in searches", BUT it actually DOES NOT. Tested with (SLES 15 SP5 (CPE_NAME="cpe:/o:suse:sles:15:sp5")): man-2.7.6-150100.8.3.1.x86_64 less-590-150400.3.3.1.x86_64 (In reply to Ulrich Windl from comment #10) > Doesn't that answer the question? > In SLES15 SP5 as root user I enteerd "man bash", then entered "/BASH", and > highlighted words were "BASH", "bash", and "Bash". It doesn't, we need to narrow down the bug. Can you confirm that "/BASH" does not work but "/bash" works? Indeed, the behavior is a bit confusing. /etc/profile from aaa_base defines: LESS="-M -I -R" so the -I is the default. The response to "-I" and "-i" looks like each of them are completely independent. But the behavior is a result of both. The default behavior is modified by /etc/profile from aaa_base:
LESS="-M -I -R"
LESSOPEN="lessopen.sh %s"
LESSCLOSE="lessclose.sh %s %s"
LESS_ADVANCED_PREPROCESSOR="no"
LESSKEY=/etc/lesskey.bin
|
When starting less (e.g. via man) and searching, the search is case-insensitive. (Verified by searching for "BASH" in "man bash") However when you enter "-i", less responds with "Ignore case in searches (press RETURN)", but when searching (e.g. pressing "n")) the search actually _is_ case-sensitive. Entering "-i" again lets less respond "case is significant in searches (press RETURN)", and search is still case-sensitive! Entering "-i" again, does not change case-sensitive searching. The help says: -i ........ --ignore-case Ignore case in searches that do not contain uppercase. -I ........ --IGNORE-CASE Ignore case in all searches. So when entering "BASH", should it be case-sensitive, or shouldn't it be case-sensitive? Entering "_i" at the start prints "Ignore case in searches and in patterns (press RETURN)", and that's true. But when it prints ""Ignore case in searches" that's not true.