top(1): reimplement header formatting as sbuf

[eadler]

Summary

The current header formatting is a giant format string that

• changes global state during the format process
• selects one of 4 different format strings and then does further conditional logic on them
• for one value uses an argument, for others, uses global variables.
• makes it hard to understand what the header will actually look like.

Make the following changes:

• use sbuf to build up the header rather than use the above pseudo-dynamic one
• Change name length to 10
• Reduce size of RES and SIZE by making humanize more aggressive

This is also a pre-req to implementing TOPCOLOR from newer versions of top(1)

Test Plan

IMPORTANT: I expect two kinds of feedback: approach, and field sizing. Let's make sure we cover approach first.

[allanjude]

Why would you reduce the username field from 13-15 down to 8 characters? There are plenty of usernames of 8-12+ characters on my systems

[danfe]

In D15801#334140, @allanjude wrote:

Why would you reduce the username field from 13-15 down to 8 characters? There are plenty of usernames of 8-12+ characters on my systems

Apparently you've missed this email of mine. TL;DR: Because most of the usernames (on most systems) are 8 characters or less. Even if they are longer (like on your systems), it makes more sense to truncate usernames than the column names and, especially, command lines.

[allanjude]

It seems to make it would make more sense to steal 1 character each from 'SIZE' and 'RES' by fixing the humanizing, so that values such as '38836K' and printed as '38M', and we know we'll never exceed 5 characters. I see value in doing 9216K instead of 9M, but once you are into 5 digits, it makes sense to go up the units scale.

This would allow the USERNAME field to fit 10 character usernames, while still gaining all of the other enhancements you have here.

[danfe]

In D15801#334199, @allanjude wrote:

This would allow the USERNAME field to fit 10 character usernames, while still gaining all of the other enhancements you have here.

Albeit a bit reluctantly, I think I can agree on 10 as a reasonable compromise (vs. current situation which is simply atrocious), and as long as column names themselves are not truncated (e.g. COMMAN or even COMMA). I would still probably patch top(1) for 8 character usernames in my local tree though. :-)

FWIW, on Linux Mint 17.3, Ubuntu 10.04, and CentOS 7.5 I see that their top(1) provides space for 9 characters in the USER column. Just a data point to consider.

[eadler]

In D15801#334174, @danfe wrote:

In D15801#334140, @allanjude wrote:

Why would you reduce the username field from 13-15 down to 8 characters? There are plenty of usernames of 8-12+ characters on my systems

Apparently you've missed this email of mine. TL;DR: Because most of the usernames (on most systems) are 8 characters or less. E

This is not true on most of the corporate systems I've worked on. We have usernames like foobar-blah-service. However,the first characters are usually sufficiently unique that I don't care :)

[eadler]

What do y'all think of making the username the maximum length username seen so far (up until a fixed max). This solves all known issues

• having to short username
• having too long username
• initialization being slow since it needs to iterate over a remote service
• having the column flicker due to a long username going in and out of use.

[allanjude]

In D15801#334441, @eadler wrote:

What do y'all think of making the username the maximum length username seen so far (up until a fixed max). This solves all known issues

• having to short username
• having too long username
• initialization being slow since it needs to iterate over a remote service
• having the column flicker due to a long username going in and out of use.

Where would you get the extra space to fit longer usernames?

[eadler]

In D15801#336271, @allanjude wrote:

In D15801#334441, @eadler wrote:

What do y'all think of making the username the maximum length username seen so far (up until a fixed max). This solves all known issues

• having to short username
• having too long username
• initialization being slow since it needs to iterate over a remote service
• having the column flicker due to a long username going in and out of use.

Where would you get the extra space to fit longer usernames?

command length? I'm also planning on taking your advice to fix the humanizing for the various fields to make them shorter.

[eadler]

rebase

[eadler]

rebase

[eadler]

Steal space from RES and SIZE; incrase username

[eadler]

• top(1): reimplement header formatting as sbuf
• Steal space from RES and SIZE; incrase username
• reduce use of +1

[eadler]

I am planning on committing this unless I hear otherwise by EoD today.

[delphij]

In D15801#336741, @eadler wrote:

Steal space from RES and SIZE; incrase username

I can't stress how much I hated this. It's 2018, can we do something smarter than assuming the terminal has a fixed width of 80 characters instead of squeezing space unconditionally?

[eadler]

In D15801#340849, @delphij wrote:

In D15801#336741, @eadler wrote:

Steal space from RES and SIZE; incrase username

I can't stress how much I hated this. It's 2018, can we do something smarter than assuming the terminal has a fixed width of 80 characters instead of squeezing space unconditionally?

I agree with you. I think I've done enough refactoring now to reasonably start adding "smart sizing" or something. Look at the previous implementation: static format strings with a lot of confusing indirection. I'm not sure what or how yet. Perhaps add/remove columns based on available width?

I won't be able to look until later this week, but I'm open to suggestions

[jamie_catflap.org]

In D15801#340849, @delphij wrote:

In D15801#336741, @eadler wrote:

Steal space from RES and SIZE; incrase username

I can't stress how much I hated this. It's 2018, can we do something smarter than assuming the terminal has a fixed width of 80 characters instead of squeezing space unconditionally?

Seconded. Even back in the late 80's we had 132 columns DEC vt320's ! :-)

Also, no offence, but I note the SIZE reduction from 6 to 5 in format_k has made things like the swap statistics more or less useless to track.

What was:
Swap: 3072M Total, 1275M Used, 1797M Free, 41% Inuse, 16M In, 19M Out

is now:
Swap: 3G Total, 1G Used, 2G Free, 41% Inuse, 16M In, 19M Out

Could you please at least make this user-configurable without needing a recompile?

Cheers

EDIT: Sorry, just noticed your followup. I note that "mtr" shoves all the stats after the hostname to the far right.. That seems overkill!

Im sure you could bump swap back from 5 to 6 if cols>>80..
Then add a few to username field, and give the rest to cmd/argv[0] ?

[eadler]

In D15801#342968, @jamie_catflap.org wrote:

In D15801#340849, @delphij wrote:

In D15801#336741, @eadler wrote:

Steal space from RES and SIZE; incrase username

I can't stress how much I hated this. It's 2018, can we do something smarter than assuming the terminal has a fixed width of 80 characters instead of squeezing space unconditionally?

Seconded. Even back in the late 80's we had 132 columns DEC vt320's ! :-)

Also, no offence, but I note the SIZE reduction from 6 to 5 in format_k has made things like the swap statistics more or less useless to track.

What was:
Swap: 3072M Total, 1275M Used, 1797M Free, 41% Inuse, 16M In, 19M Out

is now:
Swap: 3G Total, 1G Used, 2G Free, 41% Inuse, 16M In, 19M Out

Could you please at least make this user-configurable without needing a recompile?

so, I'd like to get the point when the user could provide a format string to choose what fields, sizes, etc.

One note: my CPU died recently, so I'm without any development resources for a few weeks, or maybe up to a month.

[jamie_catflap.org]

Thanks for the quick reply - I don't know if you saw my edit, but for some stupid reason I missed your previous reply when I replied.

Take all the time you need - as long as it's on the "todo" list, I'm happy!

Sorry to hear about the CPU.. What spec is it? I assume you need more than just access to another machine!

[eadler]

In D15801#342971, @jamie_catflap.org wrote:

Thanks for the quick reply - I don't know if you saw my edit, but for some stupid reason I missed your previous reply when I replied.

No worries. The shorter columns annoyed me too. A lot of my work on top(1) was getting it to the point when it makes sense to customize all of this.

Take all the time you need - as long as it's on the "todo" list, I'm happy!

If anyone else happens to get to it I'm happy to review/approve whatver too. Reverting this one part is simple enough too.

Sorry to hear about the CPU.. What spec is it? I assume you need more than just access to another machine!

https://pcpartpicker.com/list/HhycYT -- I have other machines, but that was the machine that's actually set up to have the source code, compile, test, etc.