UNIX for Dummies Questions & Answers

Spaces in file names as they're being evaluated. I just ran the finished script, sans IFS switching, and got some of this as stderr:

Code:

Evaluating  #92 of 164, happy older redhead.jpg...
happy: Failed to open the file
Exiv2 exception in print action for file happy:
happy: Failed to open the data source: No such file or directory (errno = 2)
older: Failed to open the file
Exiv2 exception in print action for file older:
older: Failed to open the data source: No such file or directory (errno = 2)
redhead.jpg: Failed to open the file
Exiv2 exception in print action for file redhead.jpg:
redhead.jpg: Failed to open the data source: No such file or directory (errno = 2)
happy older redhead.jpg: No PhotoFiltre software tag found.

BASH was "happy" (pvmi) to re-assemble the file name for me, but Exiv2 can't deal with spaces in filenames without an IFS customisation (when not reading from a 'command file,' and in the case of those it balks on unescaped extra punct. like whacks and backwhacks).

Just some FYI really. Wanted to be sure we were all on the same sidewalk with this.

BZT

---------- Post updated at 14:51 ---------- Previous update was at 14:24 ----------

Well, except for the ones it shares with the shell (file not found etc), Exiv2's errors are, as I explained, pretty "blind pew" and uninformative. What one would certainly want to know is what file threw up error X, Y or Z, and so far, I haven't been able to get a ($file,2)>/errors.txt or even a pairing of the file name and its error/s redirected to the /dev/null bitbucket. I'll keep trying, of course, but I think I may have, in the end, to wait for Andreas Huggel to mod the error reporting in his app.

In the meantime, a "dummy patch" to match the "dumbo error reporting" in Exiv2 might just be the thing to keep the screen less noisy and distinguish command errors from shell ones. In bash, it often happens that stderr redirects in scripts get ignored (personal experience as well as reading a lot of forum and BB ink on the Web are my sources on that). I don't know what they're doing over at GNU, but it's obvious they're not making it much easier for those of us who 'like' bash to keep on 'liking' it for the same reasons. This (no guarantees a 2>/dev/null will really bitbucket your error when run in a subshell) is one of those things.

BZT[COLOR="#738fbf"]

---------- Post updated at 15:52 ---------- Previous update was at 15:47 ----------

I google'd around looking for different methods of command/result error redirection from inside the script. This one seemed to suit and works well up to this point (knock on pressboard )

Lines 10-14 of my finished script now read:

Code:

MANY=$((exiv2 -g Exif.Image.Software -Pv $file) 2>/tmp/Error)
	ERROR=$(</tmp/Error)
	if [ ${#ERROR} -gt 0 ]; then
		echo -ne "$file:\n$ERROR\n">>fileerrors.txt
	fi
	rm /tmp/Error

Here I get the filename and all the errors. When the script exits, I can review the list and see what types of errors Exiv2 was running into with which files in folder X.

A nice "patch" of sorts; though only cleverly tweaked code, the silence is almost deafening in stdout, so I'm "promoting" it to a "patch" as of now

BZT

Oh.

You can put filenames in quotes to avoid that. Stopping splitting by wedging IFS with a spork seems inelegant -- what if you need it?

"${FILENAME}"