Hide Forgot
+++ This bug was initially created as a clone of Bug #1295467 +++ Description of problem: When a log file processed by logwatch contains lines terminated with <CR><LF>, <CR> is treated as a regular character rather than a part of the line break. This has two unpleasant consequences: (1) The log message may no longer match the specified pattern, making the line an unmatched entry. This may or may not be the expected behaviour. (2) When printing a <CR><LF>-terminated entry, be it matched or unmatched, the carriage return is interpreted literally which breaks the output formatting. Consider the following example, paying special attention to the **Unmatched Entries** section in logwatch output: # file /var/log/maillog /var/log/maillog: ASCII text, with CRLF line terminators # cat /var/log/maillog Sep 24 04:17:27 mail1 sm-mta[14263]: k808NQxv028473: <wyman>... User unknown Sep 24 04:19:01 mail1 sm-mta[12654]: k8O8F027026507: <cotter>... User unknown Sep 24 04:25:33 mail1 sm-mta[14462]: k8O8VWJc037652: <helman>... User unknown # logwatch --service sendmail --range all ################### Logwatch 7.4.0 (03/01/11) #################### Processing Initiated: Tue Jan 5 06:38:00 2016 Date Range Processed: all Detail Level of Output: 0 Type of Output/Format: stdout / text Logfiles for Host: myhost.redhat.com ################################################################## --------------------- sendmail Begin ------------------------ **Unmatched Entries** : 1 Time(s)@tallhart.com>... User unknown : 1 Time(s)manderly.com>... User unknown : 1 Time(s) pyke.com>... User unknown ---------------------- sendmail End ------------------------- ###################### Logwatch End ######################### Version-Release number of selected component (if applicable): logwatch-7.4.0-28.20130522svn140.el7.noarch
I don't know how perl handles this internally. Moving to perl team to get some input.
Use need-info instead of assigning-to. Perl uses platform's specific end-of-lines processing. On Linux, it is LF, thus LF is the line separator. This can be redefined, for each file handle or line processing function separately. Show me exact Perl code with input and undesired output that you think does not match your expectation. But in general, I believe processing files as is used on given platform by any other tools is fine.
Ok, I definitely don't want to fix this in general in every script "just in case". Then patch for this is quite trivial: --- /usr/share/logwatch/scripts/services/sendmail 2013-12-28 17:01:49.000000000 +0100 +++ /usr/share/logwatch/scripts/services/sendmail.new 2016-04-26 14:51:15.825294510 +0200 @@ -381,6 +381,7 @@ } # $ThisLine might have been reset (undef, or empty string) in $MatchFilter next unless $ThisLine; + $ThisLine =~ s/\r$//; if ( # informational statements of little value I wonder, how did the sendmail log end up with CRLF newlines?
See bug 1295467 comment 4.