Item5056: TWiki's logging is untidy

• User agent heuristics:
  • Internet Explorer 6 is identified as "Mozilla"
  • Firefox is identified as empty string
• User id field:
  • Most scripts log (in 4.2!) the unmodified login id
    • save with repRev logs the canonical id in the "detail" column
    • register logs the wikiname
• Log file format:
  • logYYYYMM.txt has TML-table-ready format
  • configurationlog.txt and warnYYYYMM.txt lack the closing vertical bar on each line

I failed to find any documentation about TWiki's logging, so I guess it is a WAI (Works As Implemented).

-- TWiki:Main.HaraldJoerg - 2007-12-01

Done for the warning and debug logs.

The configuration log shows a nice half-cancellation of bugs: In TWiki::Configure::UIs::Update::logChange, the code really tries hard to append " |\n", but with a plain typo, using a comma instead of a dot for contatenation. This explains why there's no vertical bar at the end. But wait... there's a line feed after every log entry, as it should be!

The explanation is that the line feed doesn't come from the broken concatenation. The individual log entries are created using CPAN:Data::Dumper, which appends a newline.

So to convert the configuration log into a TML table, the vertical bar needs to be "inserted" before the final line feed from Dumper. I'll add myself as a developer, but that's not for tonight.

-- TWiki:Main.HaraldJoerg - 2016-03-17

Harald, your change has achieved the goal of making warning and debug log entries properly formatted. But replacing a series of new lines with a space makes a multiple-line debug or warning message difficult to read. How about making it a caller's responsibility to hand a proper message to writeWarning() and writeDebug()? In other words, I suppose deleting "$text =~ s/[\r\n]+/ /gs;" is the proper middle ground. What do you think?

-- TWiki:Main.HideyoImazu - 2016-03-23

Ah, good point, especially for the debug log.

I have different feelings about writeWarning() and writeDebug(). For warnings, I'd like to parse them with software, filter out known harmless warnings, and take action on the rest. That's why I wanted them to be single-line TML table rows: easy to parse, and easy to display in TWiki. Multiline messages can be tricky to parse if there are no conventions at all about log file formats, so I would prefer to have writeWarning enforce a defined log file format instead of relying on the formatting practice of unknown callers. On second thought, after some inspection I guess it is rather reliable to assume that a new log entry starts with a vertical bar as the first character in a line. With that assumption, parsing is easy enough and processing of line feeds can be done in the formatting step.

For the debug log, you're absolutely correct. These are designed for developers, and often want to display Data::Dumper stuff. I simply didn't think enough before copypasting the lines from writeWarning.

Conclusion: For the debug log, deleting $text =~ s/[\r\n]+/ /gs; is the correct solution. For the warning log, I'd like to delete at least line feeds at the end of $text, because these tend to create stray lines in the warning log consisting of a vertical bar only. May I suggest to replace the offending line by $text =~ s/[\r\n]+$//s; in writeWarning ? The $ anchor together with the /s modifier makes sure that the pattern does not match newlines embedded in $text, so only terminating newlines are removed.

-- TWiki:Main.HaraldJoerg - 2016-03-23