Matching error to file for redirect output on the command line?
Added by Steve Wright over 11 years ago
I've taken to redirecting stderr with 2>>foo.txt, but I've noticed something when I read the foo.txt:
I get the error, but the name (or path and name) of the graphic file that prompted Exiv2 to report it isn't anywhere in the text file.
I've taken the problem to linuxquestions.org here: http://www.linuxquestions.org/questions/programming-9/bash-redirect-stderr-to-file-including-name-of-file-with-the-error-822190/ and the advice I'm getting seems to suggest that either there's a flag or option in Exiv2 of which I'm unaware, or that I should write my own error-catcher that passes the name of the "offending" file along with the Exiv2 error generated, to a text or hex file.
I've scanned the man page up and down, and I don't think there is such an option or call to a routine that would help in this direction. So I'm thinking it may be time to "ramp up" the error-reporting functions of Exiv2 with an eye toward redirection. Perhaps instead of just a "blind" direct to stdout, ie, one that gives an error without naming the file that caused it when called by a script with a loop (for/do/done, while or case/esac being prime examples of loops in bash), the error-return could include the name of the "offender" along with the error.
I recognize that when you're checking one specific file via an "exiv2 -pa" or other command and specifying one file, it might seem redundant to have it "vomit back" the file name you just gave it with the error. But consider: returns on -g options always give you the tag you specify, even when all you may want is the value of the tag you're grepping; files Exiv2 can't find use the conventional "${FNAME}: Could not write to file" syntax on those returns, so why shouldn't error-checking and -reporting be likewise as informative?
Something for Andreas and Robin to consider, anyway. Meantime, I'll look into "getting into" the app's "vest pocket" and seeing what I can "lift" from there via bash or some other scripting method (ie, write my own error-catcher).
Steve Wright
Replies (4)
RE: Matching error to file for redirect output on the command line? - Added by Andreas Huggel over 11 years ago
Thanks for your comments. I've linked them to #476, which is a long overdue issue to "ramp up" the error handling as you put it.
What's currently happening is that exiv2 (the command line tool) writes out the file name followed by the error text when it catches an exception thrown by the library. The library does that when it encounters a "fatal" issue and gives up, e.g., the image file does not exist. But there are also places where the library writes "errors" and "warnings" to standard error directly and continues processing, and these may not always have a file name (maybe because it's not easily accessible from the code which detects the problem). That happens, e.g., when it encounters invalid Exif during parsing.
Andreas
RE: Matching error to file for redirect output on the command line? - Added by Steve Wright over 11 years ago
Thanks Andreas.
Have you seen my other thread on the IFD error? http://dev.exiv2.org/boards/3/topics/563 .
I'm still puzzled by how to correct these in files. I've also never seen it happen with files with which XnView was not involved in some way in writing tag values to them. Maybe I should let Pierre know?
And as you're planning to tweak error returns, is there any chance you could also do something with iconv and the XP tags? As it stands, users get told when their strings are incorrectly-formatted, but there's nothing (besides my replies to topics 530 and 531 here in the forum) that explains how to format them correctly. And even my own researches and attempts at "translation" of plain text to the curious M$ zero-spaced/trailing-zeros ASCII format that seems nearest to what works, has occasionally come up with either plain text strings shorter than the ones input via Exiv2 or blank ones. In one of those threads, I mention that my own guess at what Microsoft uses for encoding is something close to, if not spot-on with, CS1259 (or is it 56?), which is sorely lacking in the iconv executable in both the L/unix environments I work in but seems to be present in the iconv tools or calls that you wrote into Exiv2. Again, this is me taking a shot in the (semi-)dark.
Steve Wright
RE: Matching error to file for redirect output on the command line? - Added by Steve Wright about 11 years ago
Okay, so version 0.20 has improved error-trapping.
Is it written into the man page, or in the "hopper" to go into the Guide pages, how to make use of it?
Just curious. I'll be looking around while I wait for an answer.
Steve Wright
RE: Matching error to file for redirect output on the command line? - Added by Andreas Huggel about 11 years ago
Version 0.20 does not have the improved error-trapping yet. It was added recently, after the release of 0.20. It is currently available in the SVN repository and will be in the next release, 0.21.
The exiv2 command line tool has a new option -q, which makes use of this functionality. It suppresses error messages which are otherwise written to standard error. That new switch is documented in the exiv2 -h output and in the man page.
Application developers will find the necessary documentation in the API documentation for the new class LogMsg. Pointers are also in the relevant Redmine issues.
Of course, all this documentation is currently only in the SVN repository, together with the code.
Andreas