Is it a good idea to store .fmt files in your execution path?

[L_Carver]

I've done it for a couple format files, but ExifTool (10.10) still wants the path to the files. Is there a way to streamline invoking a format file without moving it from directory to directory as I work?

Just incidentally, the directory in which I put the .fmt files appears twice when I "echo $PATH".

Carver

[Phil Harvey]

Hi Carver,

ExifTool doesn't check the path for the .fmt files.  You must specify the directory on the command line, or "cd" to that directory before running the command.

- Phil

[L_Carver]

Phil,
Thanks for the prompt reply.

I've started putting my .fmt files in ~/Pictures, though I have a few older, un-revised ones in ~/bin (no dot -- I wanted to see it whether or not I had "Show hidden files" checked in my FM). Since most of the picture files i work with are in subdirectories of ~/Pictures, it's a short path to put in an "exiftool -p" command.

It's logical that bash (or any shell) wouldn't see .fmt files in $PATH, since they're roughly analogous to signs with instructions rather than tools to accomplish some task. I think keeping .fmt's close to one's working directories is the best advice any Exiftool user can give. If there are more questions like mine over time, you may want to add this advice to a revision of the FAQ sometime down the road.

Having said that, I'm now facing a return value to variables set that include both paths. Could there be something wrong with my exiftool install?

Carver 

[Phil Harvey]

Having said that, I'm now facing a return value to variables set that include both paths. Could there be something wrong with my exiftool install?

I don't understand the question, but I don't think there is anything wrong with your installation.  The PATH environment is only used to locate the executable when running.  It isn't consulted when trying to load any other file(s).  So other file names must either include an absolute path or a path relative to the current working directory.

- Phil

[L_Carver]

The attached image is a screenshot (cropped in GIMP 2.9 before it crashed on me again) of the usual return to stdout I've been getting when I invoke a correctly-written FMT file along its path.

It also returns the same (4 times out of 5) when I enclose the path in quotes. What am I missing?

Carver

[Phil Harvey]

You need to use forward slashes, not backslashes as a directory separator.

- Phil

[Hayo Baan]

Replace the backslashes with forward slashes in the path to the fat file. You're not running it in Windows

[Phil Harvey]

  Beat you by 53 seconds!

- Phil

[L_Carver]

You need to use forward slashes, not backslashes as a directory separator.

- Phil

I do so now, I've done so since that last post, and it makes no difference. Neither does it appear to make a difference when the fmt file is in the same directory as the image file I'm working on.

The only reason that pops into my head is that something isn't evaluating my variables. That would explain how the same returns (or worse) show up in scripts like the one here

Carver

[Phil Harvey]

Instead of typing the name of the format file, try dragging and dropping the file onto the Terminal window.  There must be something wrong with your path specification.  Either that, or ExifTool can't read the file for some other reason (permissions?).  If ExifTool can't open the format file specified, it assumes that it is just a a string.

- Phil

[L_Carver]

Phil.

Permissions are owner=lcarver/group=lcarver on all of them. I know it's not likely to make a difference one way or the other, but I set the execution bit on all of them as well (not a minute ago). What I find a puzzle is why the .fmt files work that one time out of five or so, as they've done so far.

And dragging foo.fmt, etc. on an open terminal window makes the format files useless in scripts, from where I'm sitting anyway.

And I don't think it's the path specification; I've been using the same forward-slash path strings (see the script attached in my thread about comment.fmt) since you pointed out my back-whacks in that screenshot. It must be the subshell invoked by my scripts that can't find or parse them correctly, mustn't it?

Carver

[Phil Harvey]

The dragging and dropping was just to avoid typing problems which can be hard to see sometimes.

The only other thing I can think of is a DoS attack from some antivirus software (which I have seen before on Windows because this system is susceptible to these problems).  Try disabling your a/v software to see if this fixes things.

- Phil