Suppressing, redirecting errors and warnings on the command line
Added by Steve Wright almost 12 years ago
Is there a way to do this that I'm not seeing?
Working from the assumption that the former, suppressing errors altogether so they're not shown while exiv2 works on files, would involve another revision of the source code, I figured I would pursue the latter: redirecting error and warning messages to an external file.
I've been to half a dozen forums and how-to pages and it appears to me that exiv2 defies many, if not all, of the conventional methods for stdout or stderr redirection to text or ASCII files in shell scripts or CLI commands. Maybe it's because I'm trying this all in Cygwin where the BASH is pre-4.0, but I don't think so, since even the methods from that time in the course of BASH's development don't seem to work any better than the newer ones.
It occurred to me that perhaps a non-ASCII file type, similar to the .exv files generated for field and tag data, might work in this instance, but as I write this I'm still not unpersuaded there should be a simpler, more transparent (if that's the word) method that would work. Besides, hex output or something along those lines would likely mean another re-code.
So I'm picking the brains of the more-experienced coders, scripters and such folk in the exiv2 user community for advice.
S.
Replies (4)
RE: Suppressing, redirecting errors and warnings on the command line - Added by Andreas Huggel almost 12 years ago
Suppressing,
$ exiv2 -pa someimage.jpg 2>/dev/null
redirecting errors and warnings
$ exiv2 -pa someimage.jpg 2>/some/file
That's pretty conventional, actually.
-ahu.
RE: Suppressing, redirecting errors and warnings on the command line - Added by Steve Wright almost 12 years ago
Andreas,
No doubt with -p print commands you're right. I ought to have been more specific. The problem I've been having, specifically, is with -M"add..." commands in a script I just started working on.
I'll give some background here, as the example I'm using consists of a couple of variables. The script is meant to be the last step in the process of copying FixtureId tag data to the ObjectName tag in batches of jpegs. I mentioned this briefly in the "Pulling Out" thread. (I haven't decided whether or not to have exiv2 read in and parse that data from the files themselves in the final version.)
fixture is set to be the FixtureID tag data as read in from an ASCII text file which is a list of the files to be processed.
file is the name of the file in the directory, read in from the same text file.
At this point in the script, the file name has already been verified by an if-else loop, or alternately dismissed as not found by the same loop.
exiv2 -M"add Iptc.Application2.ObjectName String $fixture" modify $file
As the greater number of my jpeg files come from different places on the Web and/or Usenet, the condition and nature of their tag & packet data is often dubious, to say the least; definitely unpredictable. It's these kinds of errors I'm having a hard time passing out to an external file.
If you'd like to see the whole script in its current draft, I can certainly upload it.
S.
RE: Suppressing, redirecting errors and warnings on the command line - Added by Steve Wright almost 12 years ago
Andreas, all:
I have it worked out. Apparently in Cygwin's BASH this syntax is the best for doing redirects (of any output class) to an external file.
(somefancycommand) > file1.txt 2>&1
The space between the command and the name of the output file is necessary in Cygwin's BASH.
Leave it out and you get an empty text file as output. I'm sure there are other BASH versions or builds in other L/Unix environments that work the same way.
And as I found out, too, that the ampersand is crucial. Without it, you get a file called "1" (no quotes) with all your output and an empty text file named "file1.txt".
Now the rubber meets the road as I apply this script to a folder with over 2500 files inside it.
S.
RE: Suppressing, redirecting errors and warnings on the command line - Added by Robin Mills almost 12 years ago
Steve
Welcome to the (hideous) world of shell scripting - notice the spelling is 's hell' (s is for shear, not Steve). The cryptic heiroglyphic syntax of the shell is grim. And the different shells (csh, bash, zsh and so on) are inexplicably contrary. I can't recall ever writing a script specifically for Cygwin's bash interpreter, but I'm not surprised to hear there are IEDs just waiting to blow your foot off. Beware. Having said this, I do use bash quite a lot on Linux and the Mac and I find O'Reilly's book "Learning the Bash Shell" very helpful.
If you want to construct cross-platform scripts with clean syntax, use Python.
Robin