Python ntpq

[Eric S. Raymond]

Achim Gratz <Stromeko at nexgo.de>:
>   The waf build or install needs to create the correct shebang
> lines when a different python binary is configured, I suppose.

Oh dear Goddess, no.  I tried that approach once during GPSD's history.
It was horrible, a maintainance nightmare.  Better practice is to write your
Python so it will run under either 2 or 3. See:

http://www.catb.org/esr/faqs/practical-python-porting/

The GPSD project uses this approach successfully.  We've tried to
write the NTPsec Python this way, but the packet library is still
under active development on a Python 2 system and that sometimes
breaks Python 3 compatibility.  One of our guys, Matt Selsky, is
working on catching it up and I expect fixes will land soon.

> So I've installed python-dev to get pathon-conf for 2.7 and ntpq finally
> works.

Well, that's good.

> The shortest unique abbreviation for commands isn't working
> anymore (Hal already notedt that).

Yes, on my list, but I can't give it high priority.  I have a couple
of fires I need to fight first.

>                              Also, while it's good that the print
> can use a wide terminal now, it really shouldn't move the data to the
> right as far as possible (my text console is 320 characters wide and the
> usual graphics terminal 176 characters).  Can the fields please be
> widened only so much that they show the data without truncation?  Else
> I'd need some option to limit the width of the printout.

No can do.  You're going to have to live with using the --wide option.

If this problem could be solved with clever programming, I'd do it.
Unfortunately it's fundamental.  You can't know the right width to pad
to until you've reverse-DNsed all the addresses.  But if you do that,
you can't report even the first line until after a potentially
unbounded amount of DNS-lookup stalls.

The C ntpq code was carefully written not to require this (and had a
control flow that looked really odd unless you understood this
constraint).  The Python port preserves these properties.  Use -w.
 
> The output from the cv command mangles the timecode string from the GPS:
> 
> timecode=""$GPZDA", 120543.000="", 26="", 11="", 2016="", 00="", 00*56"="",
> 
> This used to look like that (and really still should):
> 
> timecode="$GPZDA,120543.000,26,11,2016,00,00*56",

Oh, bletch.  I see the problem.  I'm going to have to write a real
parser rather than using a naive split(",") call.

...or maybe not.  Rather klugey fix pushed.  Complain if it needs
futher work.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>