[Nut-upsdev] upscli_splitname() for upsc_list (was: Re: Default NUT PORT)

Charles Lepple clepple at gmail.com
Sun Jan 14 03:38:23 CET 2007


On 1/13/07, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> > The question is when exactly this should be converted to a number.
> > Should this be done in upscli_splitname() or in upscli_connect()?  The
> > latter would require a change in the prototypes of upscli_splitname()
> > and upscli_connect(), and an attendant change in all the existing
> > clients. When changing the "port" argument to a string, the API should
> > also define whether this is allocated (and must be freed) or not.

This reminds me: when I was working on branches/upsc_list, the
upscli_splitname() function has this comment:

/* split [upsname@]hostname[:port] into separate components */

To me, this implies that "upsname@" is optional, but I think this is
left over from an older version of NUT (since you have to specify an
upsname for upsc).

I was thinking that listing all available upsnames would be done like
this: "upsc -l hostname[:port]".

In order to reuse the upscli_splitname() code, I was thinking that I
could modify it to simply return NULL in *upsname if there is no '@'
sign. The alternative would be to have a flag (also an API change) or
create upscli_splithostname().

Since libupsclient isn't exactly ubiquitous, I would prefer changing
the semantics of upscli_splitname() and fixing whereever it is called
to check for a null upsname. Opinions or objections?

-- 
- Charles Lepple



More information about the Nut-upsdev mailing list