funflush(3)

πŸ’Ύ funflush(3) β€” the SAORD Documentation glow-up ✨

okay bestie, gather round, because this little function is the finishing touch your FITS file has been begging for πŸŽ€


🌸 NAME 🌸

FunFlush β€” flush data to output file

like, push the data out the door, no cap πŸ’…


✨ SYNOPSIS ✨

#include <funtools.h>

void FunFlush(Fun fun, char *plist)

πŸ’– DESCRIPTION πŸ’–

so the FunFlush routine will flush data to a FITS output file. that's the whole vibe. but specifically β€” and this is the part everyone forgets β€” you can call it after all your rows have been written (via the FunTableRowPut() routine) so it can add the null padding that's required to complete a FITS block 🧚 like, FITS blocks gotta be whole, bestie, and this is who makes them whole.

it should also be called after you've completely written an image using FunImagePut(), or after writing the final row of an image using FunTableRowPut(). so basically: whenever you're done-done. periodt.


🫢 the plist argument 🫢

the plist (aka parameter list, iykyk) argument is a string containing one or more comma-delimited keyword=value parameters.

so if your plist string contains the parameter copy=remainder and the file was opened with a reference file, which in turn was opened for extension copying (i.e. the input FunOpen() mode also was "c" or "C"), then FunFlush will also copy the remainder of the FITS extensions from the input reference file over to the output file 🌈 this is normally something you'd only do at the very end of processing, bestie, like the final bow at the end of the show πŸ‘‘

heads up: note that FunFlush() is called with "copy=remainder" in the mode string by FunClose(). what does that mean for you? it means if you close the output file before the reference input file, you don't have to call FunFlush() explicitly β€” unless you're writing more than one extension. see the evmerge example code for the receipts πŸ“œ

and here's the sweet part: it is safe to call FunFlush() more than once πŸ’– no fear of re-writing either the padding or the copied extensions. she's idempotent-ish and she's unbothered.


πŸ‘‘ copy=reference mode πŸ‘‘

in addition, if FunFlush() is called on an output file with the plist set to "copy=reference" and the file was opened with a reference file, then the reference extension is written to the output file. this mechanism is a super simple way to copy input extensions to an output file without processing the former at all β€” like, no work, just vibes ✨

for example, in the code fragment below, an input extension is set to be the reference file for a newly opened output extension. if that reference extension is not a binary table, it just gets written to the output file:

/* process each input extension in turn */
for(ext=0; ;ext++){
  /* get new extension name */
  sprintf(tbuf, "%s[%d]", argv[1], ext);
  /* open input extension -- if we cannot open it, we are done */
  if( !(ifun=FunOpen(tbuf, "r", NULL)) )
    break;
  /* make the new extension the reference handle for the output file */
  FunInfoPut(ofun, FUN_IFUN, &ifun, 0);
  /* if its not a binary table, just write it out */
  if( !(s=FunParamGets(ifun, "XTENSION", 0, NULL, &got)) ||
    strcmp(s, "BINTABLE")){
    if( s ) free(s);
    FunFlush(ofun, "copy=reference");
    FunClose(ifun);
    continue;
  }
  else{
    /* process binary table */
    ....
  }
}

πŸ” SEE ALSO πŸ”

see funtools(7) for a list of Funtools help pages πŸ“š


and that's the whole page, bestie πŸ’œ this was version 1.4.5, dated April 14, 2011 β€” yeah she's vintage but she still ate, and honestly? iconic behavior. mwah πŸ’…πŸŽ€πŸ¦‹