[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14505: Bug in "cat" command
From: |
Kakkar, Mayank (NSN - IN/Bangalore) |
Subject: |
bug#14505: Bug in "cat" command |
Date: |
Thu, 30 May 2013 04:39:37 +0000 |
Hi Eric,
Thanks for your prompt reply.
I am referring to the manual -> 'Sams teach yourself shell in 24 hours', which
is authored by Sriranga Veeraraghavan.
Following is example potrayed in that manual:
If multiple files are specified, the contents of the files are concatenated in
the output, but line numbering is restarted at 1 for each file. As an
illustration, the following command,
$ cat -b fruits users
produces the output
1 Fruit Price/lbs Quantity
2 Banana $0.89 100
3 Peach $0.79 65
4 Kiwi $1.50 22
5 Pineapple $1.29 35
6 Apple $0.99 78
1 ranga
2 vathsa
3 amma
So, this was what led me think this is a bug in cat command for RHEL 5.7,
because this guy must have experimented it on the RHEL machine before printing
it in the manual.
Regards
Mayank
-----Original Message-----
From: ext Eric Blake [mailto:address@hidden
Sent: Wednesday, May 29, 2013 8:57 PM
To: Kakkar, Mayank (NSN - IN/Bangalore)
Cc: address@hidden
Subject: Re: bug#14505: Bug in "cat" command
tag 14505 needinfo
thanks
On 05/29/2013 05:57 AM, Kakkar, Mayank (NSN - IN/Bangalore) wrote:
> Hi RHEL Team,
This is the upstream coreutils list; if you were trying to reach RHEL
support, you should contact Red Hat per your contract with them.
>
> I was working with cat command and testing its functionality. I learnt in one
> of the manuals that if multiple files are specified, the contents of the
> files are concatenated in the output, but line numbering is restarted at 1
> for each file.
Thanks for the report. What manual was this? I don't see anything
implying that in the 'info cat' section of the official coreutils
manual, so this is likely a bug in downstream documentation rather than
an actual problem in coreutils. But without knowing a URL of the faulty
documentation, we can't tell you where to redirect your report.
> Here, we can see that the numbering does not restarts with the new file
> contents.
coreutils' cat has never restarted numbering with new files. Maybe you
were thinking of 'sed --separate'? At any rate, we're probably going to
close this report as not a bug, although I've left it open for a bit
longer in case you can tell us more details about what led you to
believe that renumbering from 1 was expected, in case there is something
we need to improve in coreutils' documentation.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org