ntpq output should use -w

[tlhackque]

The ntpq output in show ntp detail truncates long IPv6 addresses and hostnames. This makes debugging difficult.

ntpq -w (--wide) allows the full address/hostname to be displayed. If it extends into the next column, the data is wrapped to preserve tabular alignment.

e.g.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 2.us.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.002
 1.us.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.002
 3.us.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.002
 192.168.148.255 .XFAC.          16 B    -   64    0    0.000    0.000   0.002
 ff05::101       .XFAC.          16 M    -   64    0    0.000    0.000   0.002
*2620:149:a10:30 .SHM.            1 u  316 1024    1   13.933   -1.412   3.140
+2604:4300:f35:1 10.0.0.29        2 u  193 1024    7   49.271   -1.423  11.670
+2600:3c01::f03c 80.72.67.48      3 u  192 1024    7   74.679   -1.689   5.523
+198.137.202.32  23.131.160.13    2 u  195 1024    7   68.377   -1.461   2.448
+2600:3c03::f03c 97.183.206.88    2 u  319 1024    1   12.929   -0.714   2.249
+65.100.46.164   .PPS.            1 u  189   64   34   79.346    1.268   1.553
+108.59.2.24     130.133.1.10     2 u  189 1024    7   19.370    2.374   1.537
+204.2.134.163   22.42.17.250     3 u  192 1024    7   70.051   -0.147   2.642

with -w becomes:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 2.us.pool.ntp.org
                 .POOL.          16 p    -   64    0    0.000    0.000   0.002
 1.us.pool.ntp.org
                 .POOL.          16 p    -   64    0    0.000    0.000   0.002
 3.us.pool.ntp.org
                 .POOL.          16 p    -   64    0    0.000    0.000   0.002
 192.168.148.255 .XFAC.          16 B    -   64    0    0.000    0.000   0.002
 ff05::101       .XFAC.          16 M    -   64    0    0.000    0.000   0.002
*2620:149:a10:3000::1f2
                 .SHM.            1 u  321 1024    1   13.933   -1.412   3.140
+2604:4300:f35:16::3
                 10.0.0.29        2 u  198 1024    7   49.271   -1.423  11.670
+2600:3c01::f03c:92ff:fe8c:f7c9
                 80.72.67.48      3 u  197 1024    7   74.679   -1.689   5.523
+198.137.202.32  23.131.160.13    2 u  200 1024    7   68.377   -1.461   2.448
+2600:3c03::f03c:91ff:fe3e:c3bb
                 97.183.206.88    2 u  324 1024    1   12.929   -0.714   2.249
+65.100.46.164   .PPS.            1 u  194   64   34   79.346    1.268   1.553
+108.59.2.24     130.133.1.10     2 u  194 1024    7   19.370    2.374   1.537
+204.2.134.163   22.42.17.250     3 u  197 1024    7   70.051   -0.147   2.642

Since you appear to be simply capturing ntpq output, adding the -w should not be difficult...

[dave4445]

somewhat annoying that -w doesn't actually make the output wide, just split into multiple lines keeping to a 80c width, but I see the value here

[tlhackque]

somewhat annoying that -w doesn't actually make the output wide, just split into multiple lines keeping to a 80c width

Thanks for making the change.

Some background - as often is the case, there's more to what it does than is casually apparent:

There was lengthy discussion about how to do this in the NTPd world. The design was constrained, it's a compromise.

Wrapping gives effectively 160 column lines, and only happens when a long name/address is present.

The problem with simply making the field wider is that a hostname can be 255 chars long, and an IPv6 address ~45. For an IPv6 address, 45 + the rest of the display - 62 might be tolerable at 107, but the maximum host name length + the rest yields 317. Unwieldy even on today's big monitors. Plus, most of the time a 45/255 char fixed field width would be empty; the consensus was to keep the output compact and maximally compatible with traditional output. And, there was consideration of scripts that parse the current column format. It was judged easier to adapt the wrapped version - if you want one line, simply glue lines beginning with space to the preceding line. The alternative - buffering the full table and computing the minimum required width for a given set of remotes - is ugly in C code, and results in output that's hard to parse - and with repeated invocations would cause jitter as the longest host disappears or a new one arrives.

It is trivially possible to to parse the -w output into an HTML table, at which point your browser can adjust width, change font size, wrap, provide hover text, or whatever.

And oddly enough, while 80 column terminals have largely disappeared, smartphones have arrived.

So, yes there were other choices. It wasn't a casual decision. Within the constraints of a command line utility, providing maximum compatibility, and solving the truncation problem, it was a reasonable choice. All the others were worse in some dimension.

BTW, I think I was the person who pushed for a solution to the truncation issue, but the decision on how wasn't mine. It takes some getting used-to, but it does grow on you...