Re: [pmg-devel] [PATCH pmg-log-tracker] fix #3657: allow parsing mail.log files

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On 06.10.21 15:28, Stoiko Ivanov wrote:
> On Wed, 6 Oct 2021 13:51:53 +0200
> Thomas Lamprecht <t.lamprecht@proxmox.com> wrote:
> 
>> On 06.10.21 13:46, Oguz Bektas wrote:
>>> with an optional "--maillog" parameter, we parse /var/log/mail.log.*
>>> instead of /var/log/syslog.*  
>> --mail-log
>>
>> and it may make sense to allow passing a base path to that, that would also allow easier
>> evaluation like copy of the logs from the production system and run queries on another,
>> not so important, system.
> +1 for providing a base-path - I'd even go one further and let it deal
> with the optionally gzipped logs by matching the filename (for .gz)
> instead of the 'index' (assuming that the first and second file are not
> compressed, and all consecutive files are).

yeah we can also try either match on every, that way we can better cope with
custom logrotation settings that may gzip only after .3 or so.

All that would be relatively easy to do by implementing the iterator trait for
a struct with a "base_path" member.

> 
> With that (and the assumption that `logrotate` is used) this would
> probably be usable in a configurable way for the GUI+Tracking Center)
> 
> Question is from a UX point of view how much a '-i' for single logfile and
> a '--mail-log' for a pattern of logfiles makes sense.
> 
> 

You have a point there.

First, generally my opinion is that not every option needs a short-op, as that is
something that often leads to some weird excuses/arguments for a specific letter which
a user may the see different.
 
As input is `-i` or `--inputfile` it may be sensible to use --input-base or --input-series
We already use minus as separator in a few places (--message-id, --queue-id, --search-string)
so IMO cannot really care to much for consistency here, and I'd just avoid the short opt for
this rather specific option.