Bug 106551 - inconsistent behaviour between zcat, zless, zmore
Summary: inconsistent behaviour between zcat, zless, zmore
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gzip   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
low
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-08 11:15 UTC by Robert P. J. Day
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-27 12:31:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Robert P. J. Day 2003-10-08 11:15:59 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)

Description of problem:
  the collection of file listing commands zcat, zless and zmore have
inconsistent behaviour.  if you have a gzipped file fred.gz, both
zcat and zless allow you to omit the suffix:

$ zcat fred
$ zless fred

  however, zmore *requires* the suffix, which is clearly non-intuitive.  i
haven't checked any of the other utilities (zgrep, etc.), but it might be nice
if they all worked consistently.

Version-Release number of selected component (if applicable):
gzip-1.3.3-10

How reproducible:
Always

Steps to Reproduce:
1. gzip fred (to generate fred.gz)
2. zcat fred  # works
3. zmore fred # fails
    

Additional info:
Comment 1 Bart Martens 2004-01-31 21:50:04 UTC 
If you want such a zmore, then replace zmore with this script:

#!/bin/sh
/bin/zcat "$@" | /bin/more
Comment 3 Ivana Varekova 2004-12-13 13:31:57 UTC 
Thank you for your notice. 
The problem was fixed.
Ivana Varekova
Comment 5 Ivana Varekova 2005-01-27 12:31:48 UTC 
Fixed in 1.3.3-15
Note You need to log in before you can comment on or make changes to this bug.