xpacmdnew(3)
β¨ xpacmdnew(3) β¨ β the SAORD Documentation glow-up π«Ά
okay bestie, sit down, hydrate, and let's talk about XPACmdNew from the xpacmdnew(3) manual page, because this little function is lowkey the moment π
πΈ NAME πΈ
XPACmdNew β create a new XPA public access point for commands β¨
π SYNOPSIS π
#include <xpa.h>
XPA XPACmdNew(char *class, char *name);
π¦ DESCRIPTION π¦
So here's the vibe: you call XPACmdNew and it creates a brand-new XPA public access point for commands, and all those commands share one common identifier, class:name π
It enters this access point into the XPA name server, so external processes can come find it, no cap. And XPACmdNew() hands you back an XPA struct. That's it. That's the gift π
π why one access point > a million little ones
ngl, it's often way more convenient to have one public access point that manages a whole bunch of commands, instead of making individual access points for every single command. Like, main character energy for your access point, not for each tiny command.
For example, commanding the ds9 image display is easier like this:
echo "colormap I8" | xpaset ds9
echo "scale log" | xpaset ds9
echo "file foo.fits" | xpaset ds9
than like this:
echo "I8" | xpaset ds9_colormap
echo "log" | xpaset ds9_scale
echo "foo.fits" | xpaset ds9_file
In the first case, the commands stay the same no matter what the target XPA name is. Slay, consistent, iconic. π
In the second case, the command names have to change for every single instance of ds9. So if a second instance of ds9 called DS9 were running, you'd have to command it either as:
echo "colormap I8" | xpaset DS9
echo "scale log" | xpaset DS9
echo "file foo.fits" | xpaset DS9
or as:
echo "I8" | xpaset DS9_colormap
echo "log" | xpaset DS9_scale
echo "foo.fits" | xpaset DS9_file
See the problem? π Every new instance = new names. Exhausting.
So basically: when a program is going to manage many commands, it's generally easier to define them as commands associated with the XPACmdNew() routine, rather than as separate access points using XPANew(). That's the tea β
π the important part
When XPACmdNew() is called, only the class:name identifier is specified. That's all you get up front, bestie.
Each sub-command is then defined afterwards using the XPACmdAdd() routine. So: create the access point first, then add your little command babies one by one π£
fr fr β don't expectXPACmdNew()to know about your commands yet. It just makes the spot.XPACmdAdd()fills it in.
β SEE ALSO β
See xpa(n) for a list of XPA help pages π
and that's the whole page, angel π« this was xpacmdnew(3) from SAORD Documentation, version 2.1.15, dated July 23, 2013 β go forth and make your access points, ily, bye π«Ά
π¦ where this page comes from
- debian bookworm: libxpa-dev 2.1.20-1 Β· MIT
- debian trixie: libxpa-dev 2.1.20-3 Β· MIT
- ubuntu jammy: libxpa-dev 2.1.20-1 Β· MIT
- ubuntu noble: libxpa-dev 2.1.20-1build1 Β· MIT
- ubuntu questing: libxpa-dev 2.1.20-3
- ubuntu resolute: libxpa-dev 2.1.20-3build1 Β· MIT
- ubuntu stonking: libxpa-dev 2.1.20-3build1 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms