xpacmdnew(3)

πŸ“¦
version 2.1.20 Β· 2 versions
  • 2.1.20 Β· debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 2.1.20 Β· fedora 43, fedora 44
, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ 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 expect XPACmdNew() 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 🫢