On December 18, 2005 at 00:11, Ken Bass wrote: > 1) Add a '-verbose' option which prints the filename before processing > it. Currently whenever warnings are printed (such as unable to parse > date) there is no way to tell which file caused the problem when > processing a folder. > > This change is pretty easy. I modified mhamain.pl line 345 to print > $mesgfile instead of a '.'.
-verbose is the default. You want a "more verbose" mode, like a debug mode that is more verbose, which I have considered in the past, but have not bothered to do the work for. Printing the filename only makes since for MH-style input, so your patch is unique to your input. As of now, the message-id is printed, allowing one to grep for the actual message, regardless of input. > 2) Add a resource that contains the 'input' filename. Basically, I would > like there to be a mapping between the generated data and the input > file. I am thinking MHonarc should add something like: > <!--X-Input-Filename: /var/archive/mbox/file1.txt --> This his has been discussed in the past. The input filename is not always known, and it varies based on the style of input: mbox or mh. What does exist are callbacks (see the API appendix and $mhonarc::CBMessageConverted) that provides hooks. The callbacks were added due to a request by a user. > When converting large archives, sometimes there are errors in the > processing and at least by examining the HTML source you could see > which input file causes it. The message ID is not always useful, > especially when MHonarch generate its own id. Agree on the last part. If you are processing news spools, why are there no message-ids? A problem with tracking the filename is it increases the amount of data stored in the dbfile. The callback API could be used to track the info for those interested. Alternatively, mhonarc could be modified to have diagnostic data in message pages that are preserved during edits so the info is not lost (which would require a new deliminting token to preserve such info). Of course, if such changes were made, the feature would be optional since revealing such information could be a security concern for users. --ewh