[PATCH] birdc: wider columns in show protocol output
-- Hello, The show protocol output gets more difficult to read with longer protocol names. This patch increases the column width to 15 characters. Regards Simon Index: bird-1.6.0/nest/proto.c =================================================================== --- bird-1.6.0.orig/nest/proto.c +++ bird-1.6.0/nest/proto.c @@ -1498,13 +1498,13 @@ proto_cmd_show(struct proto *p, uint ver /* First protocol - show header */ if (!cnt) - cli_msg(-2002, "name proto table state since info"); + cli_msg(-2002, "name proto table state since info"); buf[0] = 0; if (p->proto->get_status) p->proto->get_status(p, buf); tm_format_datetime(tbuf, &config->tf_proto, p->last_state_change); - cli_msg(-1002, "%-8s %-8s %-8s %-5s %-10s %s", + cli_msg(-1002, "%-15s %-8s %-8s %-5s %-10s %s", p->name, p->proto->name, p->table->name, -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, Jun 10, 2016 at 11:30:31AM +0200, Simon Ruderich wrote:
-- Hello,
The show protocol output gets more difficult to read with longer protocol names. This patch increases the column width to 15 characters.
ping - -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXlyttAAoJEJL+/bfkTDL5XMQQALGPTrVlow45jYKRxZtyDlBf 7mT6EFVH/pgmoM+qfI7J1GkW451t92nves227yDXyWMXastoW1gcNTlVlxeO5dEo 04jtkIfO4Yh4E7EeWSsb4EYGtMV1gTfzXqbUYXpefzMDV4003ja38kctsdeW8nI4 CF2gFGZCZd+YLG1V1F3RYWn1gWG9s4wEwT3CgyzASc1uFkqMxi9YZE17PMxuDLnm ENjdinJnzGZtPrtgj27Tw2ptKNfvwXrjznlVWaoO8jKDx8Li5B/SakloJWzQR0kG QJhaY5PzE+pkIG1+b5q4oVMrwaKphHg7SpyXrjEMJNUOqW53zPRtxvzLSDRpuJZ8 MX1xQllebausMSm2s7vCDuFOdZPATc0lcRlF/xjO3MMfZC+KvNrYqpJO63L5IPfO npMJAtUXp031PqXLj8Gy/ryh349pGXOTYuOHCHN+gQw0enIEu4TKBvaf5DSXeWpq A0UDt/Teje2gkQNT9IbbG+FmQ8j2kYf4kL5km94+Yy8tQur1hM+vkofj9mT4Pw1C QnqP5fVHPBUiD1Dokg1/fh+ZnoufAnhDoZoZSCaKGETh6gGM3w82Fbs78Pid1CkV wsTlO9EjXg1BCJzXZFert8VKHfAyIHIcNhiDLQVOp2yNZB/9S7V6fmk9ILgN4e6W EHXw94eRTi0p4rc3/CAp =MOY2 -----END PGP SIGNATURE-----
On Tue, Jul 26, 2016 at 11:20:51AM +0200, Simon Ruderich wrote:
On Fri, Jun 10, 2016 at 11:30:31AM +0200, Simon Ruderich wrote:
-- Hello,
The show protocol output gets more difficult to read with longer protocol names. This patch increases the column width to 15 characters.
Well, i have mixed feelings about that. It makes sense for people using long protocol names, but it takes space from the last column where error messages are sometimes presented. But 8 chars is often not enough, so i am inclined to make the column wider. Note that it breaks compatibility for tools parsing the output, so it is definitely not for 1.6.x, but we could merge in next major branch. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, Jul 29, 2016 at 11:43:12AM +0200, Ondrej Zajicek wrote:
The show protocol output gets more difficult to read with longer protocol names. This patch increases the column width to 15 characters.
Well, i have mixed feelings about that. It makes sense for people using long protocol names, but it takes space from the last column where error messages are sometimes presented. But 8 chars is often not enough, so i am inclined to make the column wider.
I'd expect that most people use terminals which are wide enough to handle a few extra characters. Or do you think 80 columns is still common?
Note that it breaks compatibility for tools parsing the output, so it is definitely not for 1.6.x, but we could merge in next major branch.
I see, thanks. I assumed that most people would use regexps to parse the output, but you're right breaking backwards compatibility is bad. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9
On Tue, Aug 09, 2016 at 12:25:14 +0200, Simon Ruderich wrote: [...]
I'd expect that most people use terminals which are wide enough to handle a few extra characters. Or do you think 80 columns is still common? [...]
Just for the record: Well, I use 80 columns most of the time. -- www.cosmokey.com
On 10.08.16 16:09, andreas@rammhold.de wrote:
On 22:06 09.08.16, Christian Tacke wrote:
Just for the record: Well, I use 80 columns most of the time.
Why not autodectet the width and if that fails default to whatever we have now?
+1 Guess doing it dynamically is a good option for terminal cli stuff. If output is truncated by a limited term width, maybe a "truncate" sign/character might help out. Another idea: provide birdc flag to print the fields maximum elements. A given delimter via extra flag/option could also make parsing of the output easier, f.e. csv. In midterm a lot of looking glass tools need a stable output "format". So maybe there should be a strategy how the output thingy should change. A json, xml or csv "renderer" would be nice. For output parsing I prefer a more parseable output format option, instead of an improved screen scrapeable console output. Just my couple of 50 cents ;-) Rgds, Stefan
participants (5)
-
andreas＠rammhold.de -
Christian Tacke -
Ondrej Zajicek -
Simon Ruderich -
Stefan Jakob