Project

General

Profile

compatible output and input format

Added by alddie minearoa over 5 years ago

Hi,

I was wondering if there are any easy ways to make the pipeline of getting "summary > modifications > applying" more straightforward. For example imagine that you extract the summary of all the jpeg tags in folder by running
$ exiv2 -px "*.jpg" > files.txt
and then do whatever change you need to do on the files.txt (for example, renaming a tag from apple to bannana, ...) and save it as mod.txt and then do something like
$ exiv2 -m mod.txt
However the later doesn't work, first of all because you need to specify the file names, which kind of seem unnecessary given that they are already specified on mod.txt, and also since the commands are not in "set xmp.tag.... [value]" format, which again I think should be pretty much easily translatable for the program given that it uses the same output format produced by exiv2.
I know there should be some way with writing a script for this, but I thought maybe the script is already written or perhaps an easier and more elegant way could be thought?

Regards,


Replies (1)

RE: compatible output and input format - Added by Robin Mills over 5 years ago

I had a discussion about something similar to this last November: http://dev.exiv2.org/boards/3/topics/2329?r=2332#message-2332 And we will add the option -m- to read commands from stdin. However I have not yet submitted that code to the trunk (#1057). Such a lot to do. Only one pair of hands and they are required to work on other matters in my life. (Not a grumble/complaint - simply a fact).

You're right in believing that we leave most of this kind of thing for the user to provide in their own script. The application exiv2(.exe) is primarily a test harness for the library and we normally use it from our test scripts which are written in bash. Please remember that the primary focus of the Exiv2 project is a Cross Platform/C++ source code library. The command-line utility exiv2(.exe) could be extended in many ways however we usually add capability to test new features of the library. As Andreas describes it "depth not width".

    (1-1/1)