Commit Graph

2346 Commits

Author SHA1 Message Date
Jim Warner
eef0c8c590 top: modify 'focus' strv function to display 'n/a' too <=== port of newlib fc3ba30a
______________________________ original newlib message

This commit just brings that 'bot_focus_strv' function
up to the same standard as the vanilla 'bot_focus_str'
guy. Namely, if there is no cmdline or environ for any
process, that bottom window will now display an 'n/a'.

[ with the nature of those string vectors, it wasn't ]
[ the same simple process found for regular strings. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
30ef314c36 top: extend 'focus' navigation to shift+tab (back_tab) <=== port pf newlib 434e2242
______________________________ original newlib message

Some of those bottom windows grow quite large, as with
the firefox environment. If one is navigating the data
using the tab key, it can be very inconvenient when an
element should be reexamined but that focus has moved.

Therefore, this commit will support the 'back_tab' key
which is a standard combination of the shift+tab keys.

Now a user can easily backup up to any missed element,
assuming a terminal emulator honors that terminfo key.

[ a gui emulator typically will honor the 'back_tab' ]
[ terminfo string, whereas a linux console does not. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
29fbc9a009 top: be more careful with memcpy length specifications <=== port of newlib c00d09ed
______________________________ original newlib message

Using 'mempcpy' was a mistake where plain old 'memcpy'
was appropriate. More importantly, the careless length
specified resulted in a SEGV under some circumstances.

[ namely, it occurred under a multi-threaded top and ]
[ the top program itself as focus + CtrlN 'environ'. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
5b2cfd607b top: modify 'Ctrl' bottom window 'str' use with 'strv' <=== port of newlib 73b4f113
______________________________ original newlib message

After satisfying increased buffer size in the previous
patch, I decided to improve the highlight accuracy for
both the command lines plus the environment variables.

Since they both may contain elements which themselves
include embedded spaces, to accomplish this goal, one
must trade vanilla strings for string vectors instead.

[ at last such library items have now been justified ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
203d75e323 top: needed 'Ctrl' bottom window fixes were discovered <=== port of newlib da36ff2b
______________________________ original newlib message

As it turns out, some of the 'environ' strings are big
enough to overrun the initial buffer sizes. And, while
no real harm was done (other than to silently truncate
the output), this patch will increase the buffer size.

While we're at it. we will normalize a few more buffer
declarations along with correcting a couple typos too.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
dbe1f42e3b doc: man page adjusted for response to keyboard inputs <=== port of newlib b8f79a7b
______________________________ original newlib message
----------------------------------- ( minus git hash )

[ and along the way, those 2 newest namespace fields ]
[ are now mentioned under that same 'X' command part ] <=== hey, we don't got them here!
[ this commit already changed for improved response. ]

[ they should have been included in the patch below. ]

Reference(s):
commit ........................................

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
cc3c2b773d top: program is now more responsive to keyboard inputs <=== port of newlib 3ea1bc77
______________________________ original newlib message
--------------------------------------------- ( none )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
27c8671ba3 doc: detail 'Ctrl' bottom window namespaces plus focus <=== port of newlib 381af1af
______________________________ original newlib message

[ along the way we will restore '^R' to keys summary ]
[ plus correct a leftover reference to 'Ctrl-V' too. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
a103b364f3 top: extend 'Ctrl' bottom window for 'memu' selections <=== port od newlib 659590b0
______________________________ original newlib message

This commit adds a prototype for a potential extension
of that tabbed bottom window capability. It introduces
a 'menu' which then provides for users' selections. It
does not actually do anything meaningful and will only
be enabled with the new #define called 'BOT_PICK_YES'.

[ since it's just a proof of concept, no attempt has ]
[ been made to add the usual NLS translation support ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
04d05b9f04 top: extend 'Ctrl' bottom window for focus via tab key <=== port of newlib de22afc4
______________________________ original newlib message

This commit introduces the 'tab' key which can be used
to highlight individual elements in that bottom 'Ctrl'
window. This can really help when reviewing such data.

[ note, normal ongoing monitoring continues unabated ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
2f683d3bcf top: expand 'Ctrl' bottom window to display other data <=== port of newlib c46a60d9
______________________________ original newlib message

This commit adds support for displaying the namespaces
in top's separate bottom 'Ctrl' window. Along the way,
the plumbing is now in place to extend this capability
to other data (if we don't run out of '^' keystrokes).

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
df36fe4d54 top: rename 'Ctrl' bottom window routines and relocate <=== port of newlib ad17ffe6
______________________________ original newlib message

This patch will just set the stage for the next commit
where we'll be adding the capability to display things
that sometimes may necessitate multiple library items.

In that effort we will be adding several new routines.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
ccc6abbf46 top: turn off the 'Ctrl' bottom window with 1 more key <=== port of newlib 3f068a66
______________________________ original newlib message
--------------------------------------------- ( none )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
ee0169fd02 top: fix a bug from when 'Ctrl' window was made sticky <=== port of newlib 793f3e85
______________________________ original commit message
----------------------------------- ( minus git hash )

In the patch referenced below the bottom 'Ctrl' window
was made to remain until it was dismissed by the user.

As such, it required abandoning a 'Cap_nl_clreos' used
when all the terminal rows had not been drawn. Instead
each line had to be cleared individually until the row
reserved for that 'Ctrl' window area had been reached.

Unfortunately, while a 'Cap_nl_clreos' didn't create a
problem for 'batch' mode, a 'Cap_clr_eol' used instead
yielded an unending loop if those rows were limitless.

So, now we will only clear that area when top isn't in
'batch' mode (which should have always been the case).

Reference(s):
. May, 2022 - bottom window made sticky
commit ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
8c336e07c6 top: avoid library shame with refactored 'Ctrl' window <=== port of newlib bc4b499e
[ sorry, but under this master branch ]
       [ the whole next narrative is frankly ]
       [ mostly pure unadulterated bullshit. ]

______________________________ original newlib message

Well darn it, whoever wrote that new library caught me
with my pants down (again?). Shoot, they were not just
down but somehow missing altogether. Here's the story.

Any item from that library supported by dynamic memory
can only be represented in user's stacks exactly once.

Should any string based enumerator be duplicated among
the items array, for any instance beyond the first the
library will return '[ duplicate ENUM ]' for a result.

That's where I lost my pants. While command lines were
given special handling (and never duplicated) I failed
to turn on CGROUPS, SUPGRPS & ENVIRON when testing the
Ctrl-G, Ctrl-U & Ctrl-N keys. If any of those 3 are on
that's when a Ctrl window sees a 'duplicate' notation.

[ and who runs top with such fields displayed anyway ]

In responding to this oops, the internals were changed
quite dramatically & vastly simplified in the process.

More importantly, the 'duplicate' results are no more.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
f45992086c top: turn off the 'Ctrl' bottom window after some keys <=== port of newlib d66c1f39
______________________________ original newlib message

To complete the implementation of this new feature, we
must address the problem created by any commands which
offer their own full replacement displays. Should that
'Ctrl' bottom window be active, a return from any such
command leaves that lower portion of a terminal blank.

While we could issue a 'TAGGED_TOSS' macro right after
invoking any of those 4 (currently) affected commands,
it is wrong to make them aware of this 'tagged' stuff.

So, I'll opt for a more generalized solution whereby a
notice regarding a corrupted screen is broadcast. Then
the logic already aware of 'tagging' can deal with it.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
619d4936ee top: allow sticky 'Ctrl' bottom window code by #define <=== port of newlib 16e202d2
______________________________ original newlib message

After making that new bottom window more persistent, I
decided to offer a build choice for somebody who might
prefer to have the rug pulled out from under him while
reviewing window contents should some target task end.

If 'TAGGED_BRIEF' is defined old behavior is restored.

[ it should be noted, however, that when this define ]
[ is active we'll lose any benefit of onetime update ]
[ for the bottom window. just like with the original ]
[ behavior, it is repainted with every update cycle. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
c9266f367b doc: adapt to the 'Ctrl' bottom window one changed key <=== port of newlib 54b949a1
______________________________ original newlib message
--------------------------------------------- ( none )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
9bd04df662 top: trade just 1 'Ctrl' bottom window key association <=== port of newlib 9ff5a4ff
______________________________ original newlib message

I grew tired of inadvertently causing a premature exit
from top when all I wanted was to review some process'
environment variables. That 'V' key was just too close
to the 'C' key so the '^V' attempt became one of '^C'.

Well, not any more. Should a user wish to see a task's
environment, it will now require the '^N' combination.

[ it also now places G/U & N/K on a similar diagonal ]

Along the way, lower case Ctrl key combinations on the
help screen were all changed into upper case versions.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
d7c3d35cdb doc: adapt to the 'Ctrl' bottom window sticky behavior <=== port of newlib ef27aea6
______________________________ original newlib message
--------------------------------------------- ( none )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
8d8eadef04 top: make the new 'Ctrl' bottom window behavior sticky <=== port of newlib 0f2a755b
______________________________ original newlib message

After using this new feature for awhile, I encountered
numerous times when that 'Ctrl' window would disappear
as I was studying the contents. This was caused by the
death of the target task but it made me think that the
window could/should persist until dismissed by a user.

Well, now it will persist until that same Ctrl key has
been struck a 2nd time or a different Ctrl key used to
target another process after positioning it on row #1.

So now, instead of that former 'moving target' type of
approach, this window is more of a 'snapshot' in time.

[ even more significant, perhaps, is the fact that a ]
[ Ctrl window will now be drawn exactly 1 time only, ]
[ instead of being repainted after each delay cycle. ]

[ this will remain true no matter how many intervals ]
[ might elapse while its contents were under review. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
60bf133184 top: add a program name to 'Ctrl' bottom window header <=== port of newlib bad7f2a2
______________________________ original newlib message

This minor addition to that new 'Ctrl' feature is more
important than it seems. It's responsible for alerting
yours truly to the 'LIBPROC_HIDE_KERNEL' bug addressed
in the very next commit. All this while, program names <=== not in this branch, cookie
for some tasks would be mysteriously replaced with the
kernel 'kworker' names. However, customary clutter for
the top process display tended to obscure such a fact.

[ and, of course, to notice the problem in the first ]
[ place required one to have the command line toggle ]
[ 'off' or perhaps to toggle its state 'on' & 'off'. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
261ed4e716 doc: add variable width data display without scrolling <=== port of newlib 6b24d11b
______________________________ original newlib message
--------------------------------------------- ( none )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
49bb9f9ae4 top: add variable width data display without scrolling <=== port of newlib fb32021e
______________________________ original newlib message

There are times when one might want to see some task's
particular variable width data. However, prior to this
commit, the only way was to first turn on a field then
scroll through it via repeated right arrow keystrokes.

[ this also required that field to be displayed last ]

Needless to say, given the potential length of some of
that variable data this could be extremely cumbersome.

Now with this patch, a Ctrl keystroke combination will
create a separate window at the bottom of the terminal
screen where such variable width data is seen in full.

[ the targeted task is the 1st task displayed, which ]
[ is a convention employed in some existing commands ]

[ the targeted data was determined by these Ctrl key ]
[ combinations: CtrlG = ctrl group; CtrlK = cmdline; ]
[ CtrlU = supplementary groups; plus CtrlV = environ ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
673fe994f9 top: eliminate the 'keys_global' redundant definitions <=== port of newlib 27f5904e
[ can't implement Ctrl-R with AGNI, it ain't present ]

______________________________ original newlib message
--------------------------------------------- ( none )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
84a1bc779a ps: that restored aix behavior gets its ultimate tweak <=== port of newlib 5edeabbd
______________________________ original newlib message

Now that this 'c' variable initial assignment has been
moved outside the looping code, there is no longer any
need to specifically check for space/comma when 'c' is
not '%'. So, let us eliminate those two lines of code.

[ i promise not to change this algorithm ever again! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
d091a67854 top: remove those winflags which restricted 'x' toggle <=== port of newlib ef8d1cb6
______________________________ original newlib message

On occasion, even as the top author, I wonder why that
'x' toggle has stopped working. Of course, it actually
was working but a locate request ('L') or other filter
('O') operation was active and thus temporarily turned
if off. Such behavior is documented in top's man page.

Well, with this patch that 'x' suppression is no more.

[ the original justification, however, remains true. ]

[ but there's really only one character which causes ]
[ any potential trouble & i'm gonna' keep it secret. ]

[ besides, if a display is corrupted, there's always ]
[ that '=' key which restores things back to normal. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
0ce9962269 top: raise %CPU maximum if large numbers of processors <=== port of newlib 7279cd8e
______________________________ original newlib message

It would appear that openSUSE was the first to release
procps-ng version 4.0.0 (in the tumbleweed distro). As
a result I checked their source rpm and found a couple
of patches I'm porting to newlib for the next release.

This particulate patch, with some changes, is openSUSE
patch 'procps-ng-3.3.10-large_pcpu.patch'. The changes
were strictly cosmetic. They involved whitespace only.

[ it should be noted that the net effect for raising ]
[ the maximum is to produce a '?' in the %CPU field. ]
[ that's because its width is fixed at five columns. ]
[ but at least the '?' won't distort actual results. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Jim Warner
40e9d0f299 top: ignore the SIGHUP signal if running in batch mode <=== port of newlib 6aec3ec9
______________________________ original newlib message

It would appear that openSUSE was the first to release
procps-ng version 4.0.0 (in the tumbleweed distro). As
a result I checked their source rpm and found a couple
of patches I'm porting to newlib for the next release.

This particulate commit was a refactor of the openSUSE
patch 'procps-ng-3.3.8-bnc634840.patch'. Unfortunately
their original patch did not have the intended effect.

That was because the amended signal handling logic was
performed well before the command line parameters were
parsed. So the global 'Batch' flag was in its 0 state.

. what follows is the original openSUSE commit message
------------------------------------------------------
Do not setup SIGHUP signal handler if we are in the batch mode

Top enables a signal handler for the SIGHUP signal (loss of terminal).  While
this makes sense for top's default interactive mode, it doesn't make any sense
for batch mode. If you run top in nohup just to collect data over time and
disconnect top finishes which is not what one would expect.
------------------------------------------------------

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-19 20:58:51 +10:00
Craig Small
8e48eb7665 fix NEWS 2022-04-11 16:39:49 +10:00
Craig Small
a7aaeaef65 sysctl: print dotted keys again
When the globbing update was put into sysctl, you could no longer
simply use the keys because one key could potentially be
multiple paths once the glob expansion occured.  Using the path
instead gave a unique output.

Except certain programs, such as salt, expected the output to use
the dotted path "kernel.hostname" and not "kernel/hostname".

We can no longer use the original key, so now for each path:
  Copy the path
  strip off /proc/
  convert all / to .

The sysctl testsuite was also updated to check for a few different
types of conversion failures.

References:
 commit 6389deca5b
 https://www.freelists.org/post/procps/some-procpsn4400-fixes,4
 https://repo.saltproject.io/

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-04-09 14:33:34 +10:00
Jim Warner
99fed92200 ps: that restored aix behavior is now even more robust
With the commit referenced below a nasty bug affecting
aix parsing was swatted. Beyond the bug, the logic was
enhanced to disallow commas in the format string since
they would otherwise be shown with their field's data.

However, there remained many characters other than ','
that could survive the edits to then be shown adjacent
to the data. Well, with this patch they won't anymore!

[ along the way we will no longer try to forgive the ]
[ use of a double '%%' prefix since that resulted in ]
[ display of one '%' and field code instead of data. ]

Reference(s):
. March, 2022 - restored aix bahavior
commit f0b7fd31db

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-09 13:00:59 +10:00
Jim Warner
f0b7fd31db ps: restore aix behavior while keeping an original fix
[ since our'master' branch will suffer the same fate ]
[ this was ported from a patch created for 'newlib'. ]

-------------------------- original newlib commit text
-------------------------- (showing our master commit)

The commit shown below broke the aix behavior that Dr.
Fink recently reported. However, in the proposed patch
the old behavior, showing garbage when '%cpu' was used
with an invalid formatting option, would appear again.

So this patch, based on Werner's patch, goes the extra
distance to prevent that. Along the way we'll disallow
commas in the aix format str to prevent their display.

Reference(s):
https://www.freelists.org/post/procps/Procpsng-400-released-with-newlib,2
. Mar, 2022 - where aix bug was introduced
commit 05187e4f17

Prototyped-by: Dr. Werner Fink <werner@suse.de>
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-01 17:21:34 +11:00
Jim Warner
edc5efcac2 top: add another tiny bit of robustness to rcfile code
At this point I don't know if the Rc.id ever carried a
value of 'b', 'c', 'd' or 'e' in a public release. But
I do know that those values ought not to be recognized
in any configuration file. Now they won't be for sure.

[ while the absence of this new check didn't produce ]
[ an error message, it would skip the initialization ]
[ of default values plus possible string extensions. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-22 07:43:56 +11:00
Jim Warner
a03a09ae1e top: do not add an extra line when rcfile is rewritten
When the configuration file is first written, there is
just the normal single newline which ends that rcfile.

However, when any existing rcfile was rewritten, there
was one extra newline '\n' character added at the end.
This will happen just once. The file does NOT continue
to grow with the extra blank lines always being added.

Anyway, this patch will put an end to such a practice.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-22 07:43:56 +11:00
Jim Warner
8269e18b3f doc: document catch-up of new scalable 'STARTED' field
[ the original newlib commit message(s) appear below ]
[ but 'cpu utilization' was not implemented to avoid ]
[ any library modifications and thus version impact! ]

------------------------------------- newlib patch ---
doc: updated with new 'start time' & 'cpu utilization'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:13:44 +11:00
Jim Warner
ed8dbd05e7 top: squashed catch-up of new scalable 'STARTED' field
[ the original newlib commit message(s) appear below ]
[ but 'cpu utilization' was not implemented to avoid ]
[ any library modifications and thus version impact! ]

--------------------------------- newlib patch #1 ---
top: added fields for 'start time' & 'cpu utilization'

This patch will exploit some new library capabilities.

[ one will raise eyebrows, the other likely will not ]

A new 'STARTED' field was added which shows the time a
process started after system boot. As such the largest
interval represents the most recently started process.

This is the field that will likely be questioned since
it's somewhat counterintuitive. But were we to instead
use TIME_ELAPSED, the value will change with every top
refresh. This will defeat any PUFF macro optimization.

The new '%CUU' field will probably be better received.
It represents the cpu usage over the life of the task.
When a process was showing high %CPU usage, this field
can be used to determine if it's an anomaly or normal.

[ and as with %CPU, %CUU shows a '?' when running in ]
[ a namespace when /proc was mounted with subset=pid ]

---------------------------------- newlib patch #2 ---
top: tweaked the recently introduced 'STARTED' support

When the 'STARTED' field was added, the width was made
the same as the 'TIME+' field. Thus, a full time could
be shown (which then included hundredths of a second).

That kind of granularity is totally unnecessary. After
all, this column is potentially confusing enough since
it is so counterintuitive. So, this commit will reduce
the width of the field with some help from scale_tics.

Henceforth it will not include those ol' centiseconds.

[ along the way let's expand the man document with a ]
[ a remainder about content representation & scaling ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:13:44 +11:00
Jim Warner
dd57e856d8 doc: document 'scale_tics' catch-up for Ctrl-E scaling
[ the original newlib commit message(s) appear below ]

------------------------------------- newlib patch ---
doc: document 'scale_tics' function for Ctrl-E scaling

[ i also tweaked that 'STARTED' narrative just a bit ]
[ since its original wording implied the value could ]
[ change, whereas it's fixed when a task is started. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:13:44 +11:00
Jim Warner
953016291a top: squashed 'scale_tics' catch-up for Ctrl-E scaling
[ the original newlib commit message(s) appear below ]

---------------------------------- newlib patch #1 ---
top: refactor 'scale_tics' function for better scaling

This patch refactors the 'scale_tics' function to more
closely parallel uptime shown on the first line of the
summary area. The old logic has been preserved through
the header file's new  #define SCALE_FORMER provision.

However, the former logic was actually a big disaster.
These are some potential problems with that old logic:

1. With respect to our time fields top no longer deals
solely with cpu time. So, the old limits of '68 weeks'
could possibly be insufficient to reflect those times.

2. Given the widths of top's new time fields, the code
never got beyond scaling to hours. For example, with a
ridiculously large span of 19 years, the scaled result
would then be shown as '167832h'. We never reached the
days ('6993d') or even the weeks ('999w') equivalents.

3. Similarly, with that 'TIME+' field and a large tics
value, results would then appear as 'MMMMMM:SS' rather
than the more meaningful 'HH:MM:SS' or days and hours.

So henceforth we will adopt these scaling conventions:

  MMM:SS.hh ... minutes:seconds.hundredths
  MMM:SS ...... minutes:seconds
  HH,MM ....... hours,minutes
  D+H ......... days+hours (with 'd' & 'h' suffixes)
  D ........... days (with 'd' suffix)
  W+D ......... weeks+days (with 'w' & 'd' suffixes)
  W ........... weeks (with 'w' suffix)

Note that, unlike our former scaling logic, that 'MMM'
portion won't be allowed to grow unconditionally. It's
limited (arbitrarily?) to 360 total minutes (6 hours).
Additionally, the 'HH' guy will be limited to 96 hours
(4 days) while that 'D' limit was set at 14 (2 weeks).

Whenever a limit is hit, scaling will advance a level.

---------------------------------- newlib patch #2 ---
top: extended 'scale_tics' function for Ctrl-E scaling

That normalization of the 'scale_tics' function in the
prior commit convinced me that I won't please everyone
with my arbitrary choices for the scaling transitions.

So, this patch will provide the users with a means for
setting their own scaling transition points with a new
toggle. Ctrl-E was chosen since the 'e/E' toggles were
already present as a means of scaling (albeit memory).

[ this toggle will also serve an educational purpose ]
[ by allowing one to see all the scaling conventions ]

The scaling a user establishes is saved in the rcfile.

---------------------------------- newlib patch #3 ---
top: enhanced 'scale_tics' function for Ctrl-E scaling

When scale_tics was refactored and then Ctrl-E support
added to top, the complete range of scaling values was
not visible. Namely, a single 'd' (days) & 'w' (weeks)
was never seen with ^E. With this commit they will be.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:13:44 +11:00
Jim Warner
05187e4f17 ps: swat insidious bug with the %cpu' format specifier
[ the original newlib commit message(s) appear below ]

----------------------------------------- newlib patch
ps: swat insidious bug with the %cpu' format specifier

Whoa, my head really hurts but this commit should help
with a speedy recovery hopefully, after it is applied.

If the '%cpu' field is used as a format specifier with
that 'o' option, you will encounter a SIGSEGV if there
is also an invalid argument on that same command line.

For example, try 'ps/pscommand -o %cpu,x' with newlib.
With any format specifier other than the '%cpu', there
is an error message, as would happen with '-o pcpu,x'.

For a 3.3.17 version of ps, there's no abend. Instead,
the program will just display a bunch of gobbledygook.
This boo-boo was found to exist as far back as v3.3.0.

[ ok, i am starting to feel very much better already ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-15 22:13:44 +11:00
Jim Warner
204194cdc4 top: trade that 'strncpy' for more efficient 'memccpy'
This patch was prompted by the merge request for pgrep
referenced below. In top's case, any performance gains
will be minimal since the now defunct strncpy was only
employed for termcap rebuilds after interacting with a
user (+ 1 other non-termcap related user interaction).

[ golly, strncpy always calls at least two functions ]
[ but usually calls a total of 3. on the other hand, ]
[ memccpy will only call a maximum of two functions. ]

And thanks to Baruch Siach for these strncpy insights.

Reference(s):
https://gitlab.com/procps-ng/procps/-/merge_requests/148

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:24:55 +11:00
Jim Warner
41b2b9dca8 top: let's eliminate some additional compiler warnings
This patch eliminates those warnings referenced below.

[ the last error shown needed a little extra cleanup ]
[ for when that '#define SCROLLVAR_NO' is activated. ]

Reference(s):
top.c: In function 'adj_geometry':
top.c:1976:20: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
 1976 |    if (Screen_cols < DOUBLE_limit) Curwin->rc.double_up = 0;
      |                    ^
top.c: In function 'zap_fieldstab':
top.c:2436:26: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
 2436 |    if (wtab[EU_CPN].wmin < digits) {
      |                          ^
top.c:2442:26: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
 2442 |    if (wtab[EU_NMA].wmin < digits) {
      |                          ^
top.c: In function 'keys_summary':
top.c:5382:45: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
 5382 |          if (w->rc.double_up && Screen_cols < DOUBLE_limit) {
      |                                             ^
top.c: In function 'task_show':
top.c:6306:13: error: expected ';' before 'else'
 6306 |             else
      |             ^~~~

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:24:55 +11:00
Jim Warner
081126f36f top: attempt to clarify the 'iokey' parameter meanings
The 'iokey' function's parameter 'action' was utilized
with literal numbers in the calling functions. So this
change will replace those literal numbers with #define
constants which, one hopes, will clarify their impact.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-17 18:24:55 +11:00
Jim Warner
101ca76786 top: tweak the heck out of some command line help text
This patch began as just an attempt to make any option
which also included an argument a little more readable
by adding one space before the '=ARGUMENT' convention.

[ by the way, i don't agree with most of those other ]
[ procps-ng programs that use an '<arg>' convention. ]
[ it's too easily misread as an 'optional' argument. ]

[ top uses a convention like that found in coreutils ]
[ albeit now with one extra space before the equals. ]

In adjusting those arguments it was apparent that many
explanations already lined up nicely at the right hand
margin. So, this commit will force right-justification
with all explanations (as we do with commit messages).

[ and as a final challenge, for those options taking ]
[ an argument, that argument was repeated within the ]
[ explanation and made the rightmost item on a line. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-01 16:11:55 +11:00
Jim Warner
5f19a76c2b top: eliminate the potential warnings '-Wsign-compare'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-01 16:11:55 +11:00
Jim Warner
7ea6ba6d4d top: avoid a potential warning '-Wmaybe-uninitialized'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-01 16:11:55 +11:00
Jim Warner
53147c9a80 top: avoid a possible warning '-Wimplicit-fallthrough'
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-01 16:11:55 +11:00
Jim Warner
292e831418 top: add visual clue when focus toggle ('F') is active
When in forest view mode, that focus toggle ('F') is a
useful tool occasionally. But, if a focused parent has
enough cloned siblings to exceed screen rows, it could
be hard to remember that such a toggle remains active.

So, this patch will provide a subtle visual clue added
to the leftmost position in the COMMAND column. Now if
the focus toggle was active, regardless of total tasks
affected, the users will always know when it's active.

Reference(s):
. 07/28/21, introduced new focus toggle ('F')
commit bdd50fa2fc
. 09/23/21, ensure focused tasks stay focused
commit d7e6c27a79

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-17 20:27:21 +11:00
Jim Warner
376d44d580 top: eliminate warnings for '-Wmisleading-indentation'
Reference(s):
. 01/08/22, newlib branch equivalent commit
commit 68995bee95d145f84c27849c47e4512da3f77a7e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-17 20:27:21 +11:00
Jim Warner
169761e186 top: eliminate every warning for '-Wformat-truncation'
Reference(s):
. 01/08/22, newlib branch equivalent commit
commit f05c78d174d3383afc3f71956c23e3e1e75bb2ed

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-17 20:27:21 +11:00