UNIX for Dummies Questions & Answers

The script:

Code:

#!/bin/bash
SAVEIFS=$IFS
IFS=$(echo -en "\n\b")
w=$(ls *.jpg | wc -l)
x=1
z=0
for file in $(ls *.jpg); do
	echo "Evaluating  #$x of $w, $file..."
	sleep 0.2s
	MANY=$(exiv2 -g Exif.Image.Software $file)
	if [[ $MANY == *PhotoFiltre* ]]  
	then
		exiv2 -M"del Exif.Image.Software" modify $file
		echo -ne "$file: PhotoFiltre software tag removed.\n\n"
		z=$[z+1]
	else
		echo -ne "$file: No PhotoFiltre software tag found.\n\n"
	fi
	sleep 0.2s
x=$[x+1]
done
g=$(echo "scale=4; $z/$w" | /usr/bin/bc)
h=$(echo "$g*100" | /usr/bin/bc)
j=$(echo ${h%??})
echo -ne "Cumulative: $z PhotoFiltre software tags purged out of $w JPEGS evaluated.\nA ratio of $j%
IFS=$SAVEIFS

Consistently, and unarguably logically, this script quits at the "done" and won't execute the lines below it. Is there some way of "telegraphing" that the incrementing variables are to be evaluated later? Or should I look for another read-in structure, like a temporary list of files in the directory and a 'while read' or 'while X is less than Y' kind of loop? It wouldn't make sense to put a concluding evaluation of the stats these "cub-scout" variables generate inside the loop, as that's when they're being incremented.

Help please.
BZT

It's not supposed to do that -- something else is going on.

I don't think this is doing what you think it's doing:

Code:

if [[ $MANY == *PhotoFiltre* ]]

Asterisks there won't match against $MANY, they match against files in ./ like you're doing with "*.jpg". If you want a regular expression, bash 3.0 has a =~ regex operator so you can just do if [[ "$MANY" =~ PhotoFiltre ]] and see if it finds PhotoFiltre anywhere in the line. I've wrapped $MANY in quotes there in case it has spaces in it.

Why are you backing up and restoring IFS? I don't see that you're using any commands that care what that special variable's value is.

Change #!/bin/bash to #!/bin/bash -x so it prints lines as it executes them so you can tell where the loop breaks and what it thinks it's doing.

Also,"for file in $(ls *.jpg)" can be more simply rewritten as "for file in *.jpg", no ls needed, no evaluation brackets needed. There's still a limit on the number of arguments however, so this kind of loop isn't appropriate for huge amounts of files.

It looks to me like it's starting the loop again for every file, but then I don't recall the last time I did an "-x" evaluation on a for-do-done loop, so....

A sample of the stdout:

Code:

+ sleep 0.2s
+ x=99
+ for file in '$(ls *.jpg)'
+ echo 'Evaluating  #99 of 171, hv7283-275.jpg...'
Evaluating  #99 of 171, hv7283-275.jpg...
+ sleep 0.2s
++ exiv2 -g Exif.Image.Software -Pv hv7283-275.jpg
+ MANY='Adobe Photoshop CS Windows'
+ [[ Adobe Photoshop CS Windows =~ PhotoFiltre ]]
+ echo -ne 'hv7283-275.jpg: No PhotoFiltre software tag found.\n\n'
hv7283-275.jpg: No PhotoFiltre software tag found.

I agree there's something else going on (it's been proven for me time and again that if a scripting "issue" can't be Google'd then it isn't an issue, and there's naught on this phenomenon, therefore....). Now that you've seen the snippet, any clue as to what?

Thanks for reminding me there was a weak(ening) ls in that "for" line. This script is a tweak on one that's about a year old, written during a short stint of not having an Internet connection. I still have a few like this.

BZT

Did you notice that there is a missing double quote on the last echo in the script? I would have expected you to have seen an error, but the behaviour might be exactly as you described all caused by the missing quote.

Bash and Kshell tend to 'chunk in' executable portions of the script only reading and parsing as much as they need to. In the case of your script it would only need to read until the end of the while loop before it can begin executing. Once the while has completed, it would read the next bit from the file, parse it and stumble on the missing quote, but not until after it had executed the while.

I don't know why it wouldn't toss an error to stderr, but if it isn't, or stderr is being redirected (I don't think you are), then it would appear not to be executing the commands after the done.

If you haven't noticed the missing quote, that might solve the issue. If you have, sorry for the rambling.

Oh, you mean, not executing stuff below the loop during the loop? Yes, that's normal.

Spot on, agama. I ran it with the fixed (?!) variables and such on a much smaller folder of files than I was "playing it on" before, and first thing to come up was "syntax error -- unexpected end of file." I cat'ed and immediately saw the missing double-quote. Never let it be said that coloured syntax formatting in a GUI text editor is an unqualified benefit -- sometimes the eye is so enwrapt in the colours that the mind is rendered blind to the errors staring one straight in the face!

My bad there. I had stderr going out to /dev/null, anticipating that the only errors I'd have seen in stdout would have been related to the files "punch branded" by PhotoFiltre or some other maker-related error. I didn't see the eof error for that reason. It's not like BASH exactly allows one to pick and choose which kind, app error or shell syntax error, one gets to redirect (or is it? I certainly haven't seen any how-to's on this score). And even the author, Andreas Huggel, says error trapping in his app needs some looking at -- presently all you get is what the error/s is/are, not what file tossed them up. It's a matter of "feeding protein" to the -V option or a more file-conscientious rewrite of the whole error-reporting section of the code. No news yet as to whether Hr Huggel has made headway.

I made the fix, and tried again. It ran beautifully. Now, paradoxically, I'm thinking a better "cure" for PhotoFiltre EXIF software "branding" tags might not be to purge them, but to erase and rewrite them in the way that won't habitually create an error call in Exiv2. Ideally such a script would sync with a query at the top (return value of same stored in a variable) to the registry asking for the exact version number of PF right down to the build string. But that's a whole other lunch date,.

Thanks again for the help.


BZT

I've never liked colour oriented editors, but mostly because half the text is not readable depending on the background colour (I prefer black). A personal choice nonetheless.

What has helped me to find these kinds of issues is running a new script with the -n option

Code:

$ ksh -n my_new_script

The -n option causes the shell to just do syntax checking and that would have tossed the error out straight away. I assume bash has a similar option, but as I work 99.9% of the time in ksh I cannot say for sure.

On the matter of redirecting errors, could you redirect the stderr from each invocation of the 'photo software' rather than the whole script. That'd give you a bit more slience, yet still see 'operational' errors from the script. Just a thought -- glad to have helped.