Bug 172230 - logwatch breaks on a stricter sort
Summary: logwatch breaks on a stricter sort
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: logwatch
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-01 19:16 UTC by Michal Jaegermann
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-11-02 12:44:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2005-11-01 19:16:44 UTC
Description of problem:

In /usr/share/logwatch/scripts/services/zz-disk_space on line 112 has an
obsolete "+4" option to sort and as result with sort from coreutils-5.92-1
it fails with "sort: open failed: +4: No such file or directory".

After replacing "+4" with "-k 5" logwatch starts work again.

AFAICS this is the only instance of using sort with "+<num>" option in all
logwatch scripts.

Version-Release number of selected component (if applicable):
logwatch-7.0-1

Comment 1 Michal Jaegermann 2005-11-01 19:52:11 UTC
Come to think of it the line 112 of zz-disk_space is truly weird.
First it has grep feding awk instead of awk putting a regexp condition,
like '/^\//$awkprog', in front of $awkprog.  The second I do not understand
what an incriminated sort was supposed to achieve.  It sorts in
"64% %7 %87" order.  Was 'sort -b -n -k 5' really intended?  Or maybe even
'sort -b -r -n -k 5'?  This is not same thing as what is there now.

Comment 2 Ivana Varekova 2005-11-02 12:44:14 UTC
Thank you for your bug report.
This problem is fixed in the last version (logwatch-7.0-2).


Note You need to log in before you can comment on or make changes to this bug.