iraf.net

In IRAF 2.15, if I try to access a FITS extension that doesn't exist, I get this:
[quote:896b7f21cb]
ecl> imhead S20100122S0063.fits[BLAH]
S20100122S0063.fits[BLAH]: FXF: extname and/or extver value not found ('BLAH')
[/quote:896b7f21cb]
In IRAF 2.16, I get this:
[quote:896b7f21cb]
ecl> imhead S20100122S0063.fits[BLAH]
S20100122S0063.fits: FXF: must specify which FITS extension (S20100122S0063.fits)
[/quote:896b7f21cb]
Whenever I specify a non-existent extension, 2.16 behaves as if I had not specified any extension at all. I can even do this:
[quote:896b7f21cb]
ecl> imhead dev$pix[sci]
dev$pix[512,512][short]:m51 B 600s
[/quote:896b7f21cb]
Is that expected? It seems odd behaviour and I'm seeing a lot of test failures due to it (so far due to an invalidated assumption in PyRAF but I suspect there will be others).Thanks again,James.

Hi Mike,We're working on 2.16 compatibility and wondering whether you have any ideas re. my above post from a few months ago?We've also collected a few more examples of behaviour that has changed or seems odd in 2.16 and it would be very helpful to know which of these are intentional and whether you have any ideas to solve the others:

By the way, we were comparing against 2.14 just for convenience, but I believe these differences are all new since 2.15 (otherwise we'd have picked them up before).

Sorry for the slow reply to this. There appear to be several issues but at first glance they all appear to be related to the new image template code in v2.16. These will be fixed for the next release but in the meantime the workaround is to do[code:1:f412109e48]cl> reset use_new_imt = no[/code:1:f412109e48]to revert to the old template code. You can put this in your package loading script to avoid it for your tasks entirely, or else edit the hlib$zzsetenv.def file to disable it for all tasks.The one question I need to this about is the behavior in your second message where specifying an extension would previously give only the first instance, but now lists them all. The new template code is meant to allow for easy expansion into lists but I think you'd only want the second behavior when you explicitly use the '@' operator, and so the default should still produce only one extension. If you agree then that'll be how I fix it.Note that patched binaries aren't possible as a workaround since this code is compiled into all tasks, but it will be fixed for the next update. Thanks for the report.

Thanks, we'll disable use_new_imt in our package for now then.Thinking about your question, it does seem a good idea to require @ in order to expand out file.fits[SCI] and otherwise only provide one extension, for backwards compatibility.Cheers,James.