iraf.net

Alice,> Why can't iraf deal with trailing zeros on filenames.Before a task sees command line arguments, the iraf CL expands them
as expressions that may include such things as numbers, operators,
variables, and functions. File or image names that consist only of
digits may be interpreted as numbers depending on precisely how they
are used. One result of this is that trailing zeroes may be dropped
from purely numerical filenames.Some ways to avoid this behavior: - quote such arguments on the command line
- append a ".imh" (or other image extension) to image names
- allow the task to prompt you for the parameters
- specify the parameters using eparam
- only pick filenames that contain a letter
(I always start with a letter)For example, your command line:> imarith 940302.060 / flath 940302f.060could be rewritten: - imarith "940302.060" / flath 940302f.060
- imarith 940302.060.imh / flath.imh 940302f.060.imh
- imarith
<answer the prompts>
- eparam imarith
<fill in the blanks>
- imarith n940302.060 / flath n940302f.060I'm sorry this caused a problem for you.Rob Seaman
NOAO/IRAF

Alice,> Thanks for your detailed reply. However if imarith had given
> me an error (as rfits does) when it made a bogus file, this
> would have saved me alot of time.I failed to point out that imarith did exactly what the CL told it
to do in your case, which is the operation: imarith 940302.06 / flath 940302f.060That is - to divide each pixel of flath.imh into the NUMBER 940302.06
and to write the result into the image 940302f.060.imh. Imarith accepts
arguments that are either images or numerical constants (and the CL allows
generating those numbers from an arbitrary expression on an image by image
basis). The task may not have done what you wanted it to do, but it
behaved as designed.Thanks for reporting this incident. The programmer who is responsible
for imarith will see this mail and may have some idea about how to
preserve the functionality of imarith (and the CL) while protecting
against future such problems.Rob