adifmt and adif-multitool: original comment at the end

[wf5w]

When using the tool I have noticed that I get the following comment at the end:

adif-multitool: original comment

I have been religiously going into an editor and removing those last 2 lines. Does this make any difference? In other words, if I import this new adi file into anything like eqsl, or qrz, n3fjp, pota.app, or any program for that matter. Will that little comment produce errors?

If so, is there a switch to suppress that comment?

You have a great utility there. I love it!

Jerry WF5W

[flwyd]

The adif-multitool: original comment text is part of a feature to preserve the original ADIF file comment while also writing a comment with the time that adifmt ran and the number of records produced. If you're just seeing adif-multitool: original comment and nothing else, I suspect what's happening is that your original ADIF file starts with a blank line or a single space, since the ADI format assumes that if the first character in a file is < that it's the start of a record, and there's no ADIF header. The adifmt pipeline is then picking up that blank-but-not-empty comment and assuming it's meaningful and should be preserved. I'm currently checking if the original comment is an empty string in cmd/io.go and should instead check for emtpy-or-just-whitespace.

It should be harmless to leave the adif-multitool: original comment text in place (it will itself be treated as a comment). If you do delete it, make sure to leave at least a blank space before <ADIF_VER:5> so that other programs can properly identify that as a header.

Oddly, I'm having trouble getting the comment-preservation feature to work while testing this out, so I'll investigate that too. If you can share the adifmt pipeline you're using, that would be helpful.

[flwyd]

I figured out what's going on.

• When I implemented file format parsing, I created a distinction between "header comments" and "file comments." In ADI, I treated all text before the first < in a field as a comment on that record; the header is treated as a record. So text at the beginning of the file like Generated on 2011-11-22 at 02:15:23Z for WN4AZY (the example in the ADIF spec) is treated as a header comment.
• Since record comments are treated as happening before the record, I needed to decide what to do with a comment that comes after the last <EOR>, so I made that the "file comment."
• When I introduced a function to help commands manage reading a collection of files and writing one output log, I carried all of the file comments forward with the adif-multitool: original comment prefix, but I didn't do any preservation of header comments, so those all get deleted in favor of the Generated at Sun, 26 Jan 2025 15:43:04 -0700 with 53 records by https://github.com/flwyd/adif-multitool comment that adifmt inserts.
• You're probably seeing "adif-multitool: original comment" and then a blank line because there was a blank line (or a line with just some space) at the end of your log file that adifmt is faithfully preserving, just in case it was important :-)

I will definitely trim space from file-level comments when doing this reconstruction; adifmt cat doesn't need to preserve the exact formatting, whitespace and all, of the original file.

I'm not sure what I want to do about header comments. It's probably not valuable to accumulate N lines of "original comment: Generated at time with X records" at the top of an ADI file after running an N-step pipeline. Maybe it's worth preserving headers comments, but skipping comments which match the pattern that adifmt produces, but the code which sets that comment format is currently divorced from the code that does comment accumulation. Additionally, it's not preserving the other header data like the original program name and version, so it seems a bit odd to try to preserve the header comment. Also, the current header format was set early in development, following the ADIF spec example, and should perhaps be revisited. The CREATED_TIMESTAMP field already has the time the log was generated, so maybe I don't need to repeat that in every log.

It's probably useful to have a command-line option to control whether this comment preservation happens. However, it would be somewhat awkward for the default value to be false, since you'd need to specify the option at each stage of a pipeline if you want to carry a comment all the way through. Maybe something like --ignore-file-comments, though I'm not sure if there should be separate options for file-level comments, record-level comments, and header comments, or if one comments option should handle all of them.

For reference, here's the header comment from an N3FJP log file I have handy:

ADIF Export from N3FJP's Amateur Contact Log 7.0.8
Written by G. Scott Davis
www.n3fjp.com
Log exported on: 10/1/2023 11:57:46 AM

[flwyd]

The latest commit does a better job of trimming space in comments. If you compile from source, try it out. If you use pre-built release, I expect to create a v0.1.19 release this week.