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 thatFunFlush()is called with"copy=remainder"in the mode string byFunClose(). what does that mean for you? it means if you close the output file before the reference input file, you don't have to callFunFlush()explicitly β unless you're writing more than one extension. see theevmergeexample 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 π ππ¦
π¦ where this page comes from
- debian bookworm: libfuntools-dev 1.4.8-1 Β· GPL
- debian trixie: libfuntools-dev 1.4.8-1.1+b2 Β· GPL
- ubuntu jammy: libfuntools-dev 1.4.8-1 Β· GPL
- ubuntu noble: libfuntools-dev 1.4.8-1.1build2 Β· GPL
- ubuntu questing: libfuntools-dev 1.4.8-2
- ubuntu resolute: libfuntools-dev 1.4.8-2build1 Β· GPL
- ubuntu stonking: libfuntools-dev 1.4.8-2build1 Β· GPL
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms