I have an MS-DOS batch command that invokes ExifTool to export separate JSON files containing specified metadata of all selected PDF files. At first, my function looked like this:
It would sometimes be ideal if I could make this work properly when I’m in Flat View for the current SOURCE folder, with multiple subfolders and selected PDFs within them. Unfortunately, if I attempt to run the command as written above, it fails to process any selected PDFs in subfolders, so I substituted {filepath$} for {file$}. That worked, insofar as all of the selected PDFs got processed, but there’s unwanted side effect: When I use {file$}, ExifTool records the file exported from as such in the first name/value pair found in the JSON:
"SourceFile": "Example.pdf"
But when I use {filepath$}, ExifTool records the full path in that line, rather than just the filename. I often need to reimport metadata from these files, while in different locations from where they were first exported, but ExifTool will only import to the specified filename or full path, so I end up having to manually remove the path information from the JSONs prior to import. I thought maybe I could get around my problem by including a CD command:
But this once again fails to process the selected subfolder PDFs. Shouldn’t the CD command be getting run again for each selected file? Or am I misunderstanding some other part of the process?
Simple commands will run each line for every file before moving to the next line, so that command would CD to all the directories and then run exiftool on each file while CD's to the last file's dir.
You'd need to use scripting to change that (unless there's a way to tell ExifTool to only use the name in the output, but I am not sure about that).
There are a couple of ways a script could do this, but this is probably the best way with a command-line tool if you want to see all the output in a single Command Prompt window:
Well, it sounded promising but doesn’t even result in an output window opening here. No idea why. I also tried the following, with several files selected in Flat View mode, just for a simpler test that didn’t involve ExifTool or any other third-party tool:
@leavedoswindowopen
CD {filepath$|..} && dir
No output window for that, either. Curious to know if it actually works for you at all, when used via Directory Opus
As said, I do have no idea what this is all about. Literally. So can't even tell if this would work for me or not.
Apparently there is more to the equation than the simple 1+1=2 that I thought.
Well, I came up with what I thought would be a sure-fire and simpler-than-scripting solution: Have a separate MS-DOS batch file with the CD and ExifTool instructions on their own lines, and then have Directory Opus call THAT, giving the full paths of selected files (one at a time) as arguments. My batch file code:
And… it only processes the first selected PDF and then stops. There is no useful output — just the normal ExifTool output for processing the one file. The current directory at the end is the sub-directory the processed file is in. Any ideas why it fails to run again for the additional selected files?
Just wanted to share that while I was doing some online research into various intricacies of MS-DOS batch coding for this project, I came across multiple references to differences/limitations of saving batch files as .BAT versus .CMD, which I’m sure you guys know way more about than I do. Bringing this up because I seem to recall having come across .BAT files that appeared to have been created by Directory Opus while looking for something among the temporary files on my computer, and the Opus manual does state that temporary batch files are created and run whenever a custom DOpus MS-DOS function/command is invoked. I couldn’t find a definitive answer on whether using & to include multiple commands on a single line is supported in .BAT, but now wonder if maybe that’s the case and is why it wouldn’t work for me?
Also, @Leo, if there are limitations like this that could affect your users, should you and @Jon maybe consider having future versions of DOpus create temporary .CMD batch files instead? Just wondering, though please educate me if my assumptions are incorrect or my understanding faulty.
I'm unaware of those differences but it wouldn't surprise me. Everything about DOS/Batch is an arcane mess, to be honest. It's best avoided as much as possible, which is why I went for scripting rather than try to find a solution using DOS/Batch. In my experience, it always takes longer and adds a lot of complexity for no benefit, while scripting adds a little complexity but works in a way that's easy to understand and isn't full of gotchas.