r.in.srtm fails to validate zip files

[kyngchaos]

r.in.srtm uses "file -ib" on the zip file to check if it has the correct mime type. "-i" seems to be a very ambiguous way to specify the mime flag. The BSD version of file (at least on OSX) uses "-i" for the "do no classify" regular files option, and "-I" (uppercase) for the mime option, though has "-i" for mime listed as a legacy option. GNU file and old UNIX versions use "-i" for the mime option. SUS does not have mime as a minimum option to support.

It looks like all have the extended "--mime" flag. Attached is a patch to use that flag. There should probably be a way to handle the possibility of a system having a "file" command without any mime flag, but I don't know how to handle that, and it may not be critical.

[hamish]

could 'unzip -t' help?

what does the IEEE standard say about the -i file option?

Hamish

[kyngchaos]

I don't know why it was changed ([19303]), but it used to try unzipping immediately, and testing whether that failed. "unzip -t" tests by unzipping anyways before the real unzipping, thus wasting time (though it is only in memory).

[kyngchaos]

Interesting - I was wondering why I didn't notice this before, I know I've converted SRTM since that change. I totally forgot to check older OSX versions. OSX 10.5 has "-I" as the mime flag. OSX 10.4, and probably previous versions, has "-i" as the mime flag.

what does the IEEE standard say about the -i file option?

Dunno, but the SUS standard (which OSX 10.5 now conforms to) has "-i" as the "do not classify regular files" option. ​http://en.wikipedia.org/wiki/File_%28Unix%29#Usage

[kyngchaos]

I guess my main concerns are:

• the "--mime" flag is standard on modern systems - it looks like it.
• I've noticed that people tend to avoid the double-dash long versions of flags, but I don't know if there is a technical reason other than less typing. In this case it avoids confusion in the -i/-I short flag.

If there are no objections to "--mime", I'll patch r.in.srtm.

[hamish]

SUS says:

​http://www.opengroup.org/onlinepubs/009695399/utilities/file.html

--mime is not mentioned.

re "why was it changed" in r19303: it never used zip to test, it was using ls to look for a file with a .zip extension. (input= refers to the tile name not the file name)

-ls -1 "$FILE.hgt.zip" | grep zip > /dev/null
-if [ $? -ne 0 ] ; then
+# really a ZIP file?
+if [ "`file -ib $FILE.hgt.zip`" != "application/x-zip" ] ; then
   echo "$FILE.hgt.zip is no zip file."
   exit 1
 fi

for one thing "echo $foo.zip | grep zip" was always true.

Perhaps the reason for the test had to do with downloaders creating incomplete or 0 byte files, or having wrongly named files?

I've removed file and added a call to unzip -t in 6.3 trunk.

waiting to backport to 6.3.0's branch and close the bug until someone tests the change please.

Hamish

[hamish]

see r30046