Bug 666084
| Summary: | No longer displays original file when input pipe script produces no output | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt McCutchen <matt> |
| Component: | less | Assignee: | Vojtech Vitek <vvitek> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | hripps, npajkovs, tmz, vvitek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-21 09:15:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Thank you for the report, Matt. I should have changed man page example as well, sorry for that. I am discussing the changes with upstream developer right now, so I will let you know about the resolution. Matt, do you know any 3rd party package that ships it's own modified LESSOPEN variable (and which value begins with pipe character)? $ repoquery --whatrequires --alldeps less | sed 's/\([a-zA-Z-]*\)-[0-9]*.*/\1/' | sort | uniq backup-manager calc colordiff firehol git GMT gzip less man-db octave R-core I have found just one LESSOPEN modification in those packages: zless.in:56:LESSOPEN="|gzip -cdfq -- %s"; export LESSOPEN - and this works OK, as it returns exit status of gzip program itself. No. The third party input pipe script in question is one that I wrote and installed manually on my system. Obviously it is not part of Fedora. But the behavior change to "less" broke a documented API, which is discouraged under the updates policy. In my view, bug 615303 is a nit and does not justify such breakage. I just got bitten by this as well in Fedora 13. I've had my own lesspipe.sh script for years and was surprised to see it break after the recent less update. I'd never run into the bug that the update fixed either, FWIW. less-436-10.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/less-436-10.fc14 less-436-9.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/less-436-9.fc13 Fixed in less-436-12.fc16, less-436-12.fc15, less-436-10.fc14 and less-436-9.fc13. Can you guys confirm there is no other regression? less-436-12.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/less-436-12.fc15 less-436-10.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. less-436-12.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. less-436-9.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: The behavior of "less" has changed to not show the original file when an input pipe script ("lesspipe.sh") produces no output. The script must exit nonzero for the original file to be shown. This is a superior design, and it makes bug 615303 go away, but it breaks third-party input pipe scripts. IMO, this is not an acceptable trade-off under the updates policy for a stable release (https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases). The man page was not updated either. Version-Release number of selected component (if applicable): less-436-8.fc14 How reproducible: Always Steps to Reproduce: 1. Copy the example lesspipe.sh script from the man page to the current directory. 2. echo foo >file 3. LESSOPEN="|$PWD/lesspipe.sh" less file Actual results: An empty file is displayed. Expected results: "foo" is displayed.