option to ignore unmatched lines

[hvisage]

Have situations I list things like ZFS snapshots, with some "custom" snapshot names in the list or the list might include a couple of snapshots.

Instead of throwing a "Error parsing" line, perhaps have an option to ignore any unmatched lines?

[apreiml]

An ignore unmatched may not be that hard to add.

Though I personally would filter the input before it's send to prunef. You could do it easily with something like find . -name "backupname-*". What do you say?

[hvisage]

Well, I already does things like this:

zfs list -t snap  data1/ClientA/mariadb04_log > /tmp/list
grep frequent /tmp/list | prunef --keep-minutely 2880 --keep-hourly 48 'data1/ClientA/mariadb04_log@zfs-auto-snap_frequent-%Y-%m-%d-%H%M'
grep hourly /tmp/list  | prunef --keep-hourly 336  'data1/ClientA/mariadb04_log@zfs-auto-snap_hourly-%Y-%m-%d-%H%M'
grep daily /tmp/list  | prunef --keep-weekly 12 --keep-monthly 24 --keep-yearly 20 --keep-daily 30  'data1/ClientA/mariadb04_log@zfs-auto-snap_daily-%Y-%m-%d-%H%M'

but where it then becomes "fun" is where I have another filesystem, where I have to do this:

zfs list -t snap  data1/ClientB | grep "data1/ClientB@zfs-auto-snap_frequent" | prunef --keep-monthly 12 -- keep-weekly 12 --keep-daily 30 --keep-hourly 72 --keep-minutely 1440 'data1/ClientA/mariadb04_log@zfs-auto-snap_frequent-%Y-%m-%d-%H%M'

and the reason I need that full grep, is 'cause (a) the headers and (b) there are some 'data1/ClientB@zrep0XXX' used for the replication pushes, so in essences, the grep would've been (in both the above cases) superfluous if prunef would've --drop-unmatched-lines

If there are a reason not to do it, I know how to do it, just that might've been an easy less commands

[apreiml]

One thing that speaks against this is that you won't notice time parsing errors. If you mess up the date format string, like again swapping %m with %d, it will work at the first 12 days of the month and than you'll notice that prunef is failing.

So I guess when dropping unmatched one, we should at least fail, if the time format is wrong, but the other characters match.