RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 615303 - less fails to decompress empty files that have been gzipped
Summary: less fails to decompress empty files that have been gzipped
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: less
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jozef Mlich
QA Contact: Martin Frodl
URL:
Whiteboard:
Depends On: 579251
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-16 13:11 UTC by Nikola Pajkovsky
Modified: 2020-01-17 15:25 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the lesspipe script returned incorrect exit status codes. As a consequence, the less utility failed to decompress empty files that had been compressed with the gzip utility, and an unwanted message was displayed. With this update, a pipe character ("|") has been added in front of the LESSOPEN environment variable to enforce a new default behavior of lesspipe. For backward compatibility, lesspipe has the same behavior if LESSOPEN remains unchanged. As a result, the less utility now detects and displays empty files correctly.
Clone Of: 579251
Environment:
Last Closed: 2014-06-16 11:25:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch to fix empty lessopen.sh pipe output (1005 bytes, patch)
2010-12-08 15:21 UTC, Vojtech Vitek 		no flags Details | Diff
New version of lesspipe.sh with correct exit statuses (needed by previous patch) (1.60 KB, text/plain)
2010-12-08 15:32 UTC, Vojtech Vitek 		no flags Details
1) lesspipe.sh with correct exit statuses (2.06 KB, text/plain)
2011-07-22 16:47 UTC, Vojtech Vitek 		no flags Details
2) Backward-compatible patch to fix empty lessopen.sh pipe output (2.33 KB, patch)
2011-07-22 16:50 UTC, Vojtech Vitek 		no flags Details | Diff
Patch extracted from upstream less to fix the issue (2.40 KB, patch)
2013-02-06 18:33 UTC, Martin Bříza 		no flags Details | Diff
Show Obsolete (2) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0755 0 normal SHIPPED_LIVE less bug fix update 2014-06-16 15:23:35 UTC

Internal Links: 1254837

Description Nikola Pajkovsky 2010-07-16 13:11:25 UTC 
+++ This bug was initially created as a clone of Bug #579251 +++

Description of problem:
If you have a zero-byte file that has been gzipped, trying to view it via "less emptyfile.gz" results in:

"emptyfile.gz" may be a binary file.  See it anyway?

Version-Release number of selected component (if applicable):
less-436-2.el5

How reproducible:
Always

Steps to Reproduce:
This works correctly:
  # echo test >testfile
  # gzip testfile
  # less testfile.gz

This doesn't:
  # >testfile
  # gzip testfile
  # less testfile.gz
  "testfile.gz" may be a binary file.  See it anyway?
  
Actual results:
"testfile.gz" may be a binary file.  See it anyway?

Expected results:
It should display the decompressed contents of the .gz file, just as it does with gzipped text files >0 bytes.

Additional info:
Also seen on Fedora 12's less-436-6.fc12.i686

--- Additional comment from npajkovs on 2010-07-16 09:02:40 EDT ---

Created an attachment (id=432385)
less-436-less-fails-to-decompress-empty-files.patch

proposing patch
Comment 1 Bill Nottingham 2010-07-16 16:42:29 UTC 
It is too late for exceptions. Moving to 6.1.
Comment 6 Vojtech Vitek 2010-12-08 15:21:44 UTC 
Created attachment 467496 [details]
Patch to fix empty lessopen.sh pipe output
Comment 7 Vojtech Vitek 2010-12-08 15:32:15 UTC 
Created attachment 467503 [details]
New version of lesspipe.sh with correct exit statuses (needed by previous patch)

Testing the patch:

$ tcsh # because of previous issues with printexitstatus
$ set printexitvalue=1
$ env SHELL="/bin/tcsh" LESSOPEN="|`pwd`/lesspipe.sh %s" ./less <file>

<file> is for example "empty.gz"
(created by $ touch empty; gzip empty)
Comment 8 Nikola Pajkovsky 2010-12-09 09:49:28 UTC 
Comment on attachment 467496 [details]
Patch to fix empty lessopen.sh pipe output

looks good to me, feel free to commit it and try to send patch to upstream ;)
Comment 9 Jordan Russell 2010-12-27 05:06:04 UTC 
Thanks for the work on this. :)

Unfortunately, however, the update on Fedora (less-436-8.fc14.i686) seems to have introduced a new regression. It will no longer decompress files ending in .1.gz -- empty or not:

# echo test | gzip > messages.1.gz
# less messages.1.gz
"messages.1.gz" may be a binary file.  See it anyway?

messages.1.gz = a rotated copy of /var/log/messages produced by logrotate with the "compress" option enabled.
Comment 10 Vojtech Vitek 2011-01-03 09:19:12 UTC 
Thank you for reporting this, Jordan.
I have fixed the regression in current Fedora releases, so you can get an update soon.
Comment 11 Vojtech Vitek 2011-02-09 15:57:01 UTC 
Waiting for upstream comment.

I have prepared backward-compatibility patch as well (requiring two vertical bars in row), to preserve functionality of third party LESSOPEN scripts that disrespect correct exit statuses.
Comment 12 Suzanne Logcher 2011-02-15 21:40:36 UTC 
This issue was proposed for RHEL 6.1 FasTrack but did not get resolved in time.
It has been moved to RHEL 6.2 FasTrack.
Comment 14 Suzanne Logcher 2011-02-15 22:04:02 UTC 
This issue was proposed for RHEL 6.1 FasTrack but did not get resolved in time.
It has been moved to RHEL 6.2 FasTrack.
Comment 21 Vojtech Vitek 2011-07-22 16:47:36 UTC 
Created attachment 514738 [details]
1) lesspipe.sh with correct exit statuses

This file is now used in current Fedora releases..
Comment 22 Vojtech Vitek 2011-07-22 16:50:09 UTC 
Created attachment 514739 [details]
2) Backward-compatible patch to fix empty lessopen.sh pipe output

This patch is enabled by using two '|' colons in row at the beginning of the LESSOPEN variable to prevent backward-compatibility of third party LESSOPEN scripts/commands.
See patched man pages for more information.
Comment 25 Vojtech Vitek 2011-08-10 14:18:03 UTC 
Moving to 6.3, as we still don't have any response from the upstream.

Even though the patch is backward-compatible also with 3rd party scripts (and Fedora proves it's functionality), we can't be sure the patch won't break LESSOPEN string compatibility with future upstream versions. For example, this could eventually cause some difficulties while upgrading to RHEL-7 and using customized or 3rd party scripts.

Setting Cond NACK UPSTREAM as well.
Comment 26 Vojtech Vitek 2011-09-14 18:41:41 UTC 
Upstream response:

> > Hi Vojtech,
> > Sorry I haven't responded earlier.  I did receive your patch but haven't had much
> > time to work on less issues lately.  My major concerns would be the two points that
> > you yourself raised -- its use of /dev/null is Unix-specific, and the potential
> > incompatibility with existing LESSOPEN scripts that may return random exit codes.
> > The second issue is the most serious, and I think we'd need to have some way to 
> > distinguish "new" LESSOPEN scripts that use the exit code for this purpose from
> > old ones.
> Actually, in Fedora, we are using *two vertical bars* in row as a workaround:
>     eg. LESSOPEN="||/usr/bin/lesspipe.sh %s"
I see.  I'm a little leery of the proliferation of cryptic characters appearing at the start of the LESSOPEN string, first "|", then "-|", now "||" and I suppose "-||" is also possible.  But it's not bad.  If we can find a way to solve the /dev/null issue, it would be fine.

--Mark
> 
> See the following link for the whole Fedora changeset:
> http://pkgs.fedoraproject.org/gitweb/?p=less.git;a=blob;f=less-436-empty-lessopen-pipe.patch;h=69f84ca1287c55e5d948d0be3763797941fc3523;hb=HEAD
> 
> I think it would be great if we could unify this "new" exit code behaviour in the similar manner,
> as it is backward-compatible with old scripts, and also it provides the "correct" behaviour.
> 
> So if you agreed with similar solution, we would have to deal just with /dev/null issue.
>  
> - Vojtech
> >
> > --Mark
Comment 27 Vojtech Vitek 2011-09-14 18:49:25 UTC 
Upstream won't merge the changes until we have the "/dev/null" solution fixed for non-unix systems. Still Cond NACK UPSTREAM..
Comment 29 Suzanne Logcher 2012-02-14 23:00:42 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 30 Martin Bříza 2012-06-06 13:16:23 UTC 
The component has changed its owner to me, so I'm assigning the bug to myself.
Comment 31 Martin Bříza 2012-06-18 08:28:35 UTC 
I wrote a portable patch and sent it to upstream to check it. Mark Nudelmann (the author) replied on Friday:

>Hi Martin,
>Thank you for the patch.  I have actually implemented this feature in a
>different way, using a special filename similar to the way FAKE_HELPFILE
>is used.  It's kludgy, but at least it has precedent.
>
>I'll release this in a beta soon.
>
>--Mark
>
>On 6/13/2012 6:56 AM, Martin Briza wrote:
>> Hello,
>>
>> I'm the new maintainer of less in RHEL and Fedora and Vojtech told me
>> about your communication regarding empty files as output from input
>> preprocessor.
>> I think I solved the portability problem with opening /dev/null to get
>> empty output to print with a small hack - opening the input file again
>> (as it should still be there to be read) and seeking to its end to get
>> EOF immediately.
>> There is the patch (based upon the one Vojtech has sent you) attached to
>> this mail.
>> I know it's not a clean solution but I'm afraid there isn't much more
>> options. Anyway, I'll understand perfectly if you refuse it.
>>
>> Thanks in advance,
>>
>> Martin Briza

I'm absolutely sure his implementation is better so I will wait until he releases his version and propose merging it into our tree.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 33 Martin Bříza 2013-02-06 18:33:15 UTC 
Created attachment 694089 [details]
Patch extracted from upstream less to fix the issue

This issue can be fixed with this upstream fix (extracted from less-451 as the author releases only the full package).
Fixing this will also need modifying less.csh and less.sh to set the LESSOPEN variable to contain "||" instead of "|" and change lesspipe.sh to attachment 514738 [details].
Comment 43 Jozef Mlich 2014-05-22 11:25:49 UTC 
It seems, the attached patches wasn't including fixes for rhbz #718498.
Comment 47 errata-xmlrpc 2014-06-16 11:25:52 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0755.html
Note You need to log in before you can comment on or make changes to this bug.