iraf.net

A fits file that works fine on a 64.bit Debian machine running 2.14 doesn't on v.215alpha installed from its latest update into /iraf/iraf on up to date Fedora 13 laptop w/ 4 GB RAM. implot works fine on the file
imhead produces No write permission on file (String_File) on my file
However imhead works fine on dev$pixsplot thinks the file has no lines, works fine on v2.14The file in question displays fine in ds9 6.2 and has full rwx permissions.Are these installation errors or bugs? What next to try? Thanks

Update. On the same laptop I just reinstalled 2.14.1 core & noao binaries, and the file opens fine in splot etc So this is indeed an issue w/ 2.15alpha.

I'd have to see the FITS file to comment specifically, could you please upload it to the anonftp at ftp://iraf.noao.edu/pub so I can have a look?? One of the first things I'll do is run the FITSVERIFY task (from CFITSIO, not an IRAF task) to validate the file format. The IMHEAD/SPLOT errors could be explained by a malformed file, but might also be separate bugs. Dev$pix is a different file format (IMH), it would be interesting to know whether all FITS files fail (e.g. does a "imcopy dev$pix foo.fits" likewise fail for 'foo.fits') or if it is just this one.

Mike, the file is now there as 0009.***.fitsI had already copied dev$pix as fits and imhead works fine on it in2.15alpha
So, I agree that this suggests that the header of the file uploaded is wonky in 2.15 although it works fine in 2.14.1

The PARAM0, and PARAM61-63 header keywords contain non-ascii character, i.e.
these are temperatures and the comment uses the degree symbol rather than "deg C". I suspect this is the cause but will have to verify it. It makes some bit of sense this would show up on 64-bit and not 32-bit because the conversions used between native formats are slightly different, my guess is this is causing a truncated header read of some kind.In any case, the file is technically not valid FITS but I'll see if I can make the system a bit more tolerant.

Ah, that does make sense. I guess the assumption was that the comment field can have any ASCII character. Presumably the standard says otherwise. I'll inform our programmer once you confirm, but I suspect that most of the SOAR instrument headers have these.