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>
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>
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>
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>
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
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>
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>
When autogroups are active programs such as renice and
nice are basically useless because the nice value will
only affect the target task priority relative to other
processes in the same autogroup. So to accomplish what
we thought of as renice, /proc/<pid>/autogroup must be
changed. Altering a single member in an autogroup will
also affect every other member of that same autogroup.
Since top's renice provision ('r') suffers constraints
like those of the stand alone nice/renice programs, we
will now provide a means to manipulate that nice value
found within some process' /proc/<pid>/autogroup file.
[ to alter this file for other user's tasks requires ]
[ root privileges, as does setting a negative value. ]
[ however, unlike that 'r' command, this new command ]
[ allows raising *and* lowering all positive values. ]
Reference(s):
. Aug 2021, autogroups added to librady
commit 631e5d91f3
. Aug 2021, autogroups added to top
commit b789b46f84
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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>
When top's rcfile was reorganized, trading that 'char'
based field representation for the 'int' scheme, there
was a function prologue that should have been changed.
Thus, this patch will correct that original oversight.
Reference(s):
. Mar, 2022 - rcfile reorganized
commit 46aa96e438
Signed-off-by: Jim Warner <james.warner@comcast.net>
When we transitioned from 'char' based fields to 'int'
proper initial cursor positioning (highlight) was lost
in the 'fields_utility' function. The highlight should
appear on the current sort field. Instead, however, it
was often positioned on the first field listed or some
completely different field other than that sort field.
So this patch will restore the master branch behavior.
[ and on the assumption that a sort field is visible ]
[ we will search first for a field with the 'on' bit ]
Reference(s):
. Mar, 2022 - trade 'char' for 'int'
commit 46aa96e438
Signed-off-by: Jim Warner <james.warner@comcast.net>
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.
[ the net result is that now a user with such a file ]
[ will see the 'incompatible rcfile' message instead ]
[ of that misleading 'window entry corrupt' message. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
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.
[ along the way i fixed an unrelated whitespace oops ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When %CUC was added in the commit shown below I failed
to update the man document. This fixes that oversight.
Reference(s):
commit cfa5538832
Signed-off-by: Jim Warner <james.warner@comcast.net>
This new integer based version of 'fieldscur' deviated
a bit too much from that character based logic when it
comes to ancient 3.2.8 rcfile support. This results in
an inappropriate extra field shown as the last column.
If we're truly dealing with 20 year old 3.2.8 rcfiles,
it's important the 3.3.9 extension (RCF_PLUS_H) not be
concatenated to what was read. That's because a search
for the special SUSE characters will always find a '\'
in the 26th position (after normal 3.2.8 'fieldscur').
[ for symmetry, we'll also avoid RCF_PLUS_J (3.3.17) ]
All other 'old' rcfiles are transformed without error.
Reference(s):
. Mar, 2022 - 3.2.8 support restores
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will restore the previously abandoned older
rcfile support. To be honest, I wasn't sure this would
be possible given the vast difference between formats.
But after some very intense hacking our newlib top can
again fully support seamless migration from some older
'char' based file to this new 'int' based file format.
[ top even supports a 20+ year old 3.2.8 config file ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
As I speculated in a prior commit, this patch will now
demonstrate how simple it is to extend the upper limit
of supportable fields. With these changes we'll now go
from facing the old limit of 86 to a new limit of 100.
No other changes are needed nor is any logic impacted.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With each of those references shown below, the maximum
number of fields was increased. However, with a 'char'
based implementation we're nearing the upper limits of
total displayable fields. We currently use 76 of a max
of 86 fields. With extra effort, 94 might be possible.
But 94 is the absolute upper limit of possible fields!
Moreover, the current implementation yields characters
that were unprintable in the rcfile. This could become
an issue with that 'inspect' feature when/if an rcfile
is edited to add entries (as opposed to using 'echo').
So, with this commit the internals of field management
has been completely reimagined. It is now based on the
integer type, not a character. And whereas that former
design used the high order bit to show the 'on' state,
thus yielding an unprintable character, the new design
uses the low order bit for the state. As such, numbers
will be kept small and an even number will be an 'off'
field whereas an odd number will become an 'on' state.
The bottom line is that this new design will afford an
unlimited number of new fields while keeping an rcfile
completely free of that potential unprintable garbage.
And it is embarrassingly easy to extend the maximum of
supportable fields from the currently implemented 100.
Who knows, maybe a future patch will prove this point.
[ unless a subsequent commit proves otherwise, given ]
[ the dramatic differences in rcfile contents, i had ]
[ to abandon the practice of supporting old rcfiles. ]
Reference(s):
. Nov, 2013 - RCF_PLUS_H introduced
commit af4e6533ba
. Jul, 2016 - RCF_PLUS_J introduced
commit d5c5051fb3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This warning was added after discovering openSUSE uses
the option with (at least) their 'tumbleweed' version.
The man document sections impacted are: 4e, 5d and 5e.
That is where it was asserted sort column highlighting
would be temporarily turned off if search ('L') and/or
filtering ('O') is active. This option makes it false.
[ shame on suse for not also correcting the man page ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just compliments a change referenced below
by providing the value which includes reaped children.
Reference(s):
. Feb, 2022 - added %CUU field
commit 7647e96b0a
Signed-off-by: Jim Warner <james.warner@comcast.net>
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.
Reference(s):
. Mar, 2022 - introduced ^E tics scaling
commit 402bf1903b
. Mar, 2022 - refactored scale_tics
commit 71eb90c1b2
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ 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>
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.
Signed-off-by: Jim Warner <james.warner@comcast.net>
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.
Reference(s):
. Feb, 2022 - added 'ELAPSED'
commit 9348d3b008
. Feb, 2022 - added 'STARTED'
commit 7647e96b0a
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the 'STARTED' field was added, in the message for
the commit referenced below, I explained why 'ELAPSED'
shouldn't be implemented though it might be preferred.
Well, after climbing out of my box to do a little more
thinking, I came up with the way to add that 'ELAPSED'
field while avoiding the possible performance penalty.
Just do not show what would change with every refresh!
If we do not show the seconds portion of a scaled tics
amount then the problem goes away. And this comes with
an additional benefit. The HH,MM (hours,minutes) style
then is readily compared with that system uptime shown
as HH:MM. The only difference is just the comma/colon.
[ assuming the top uptime/load average toggle was on ]
Reference(s):
. introduced 'start time' field
commit 7647e96b0a
Signed-off-by: Jim Warner <james.warner@comcast.net>
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 ]
Reference(s):
. introduced 'start time' field
commit 7647e96b0a
Signed-off-by: Jim Warner <james.warner@comcast.net>
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 ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The assignment was originally created to reduce length
of one line of code (i.e. for readability). But we can
achieve this objective without adding executable code.
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
There was a potential problem with these macros should
that '#define SCROLLVAR_NO' be active and they were to
appear in an 'if' statement (like is necessary for the
master branch version of top under that EU_CMD label).
[ now they're always usable without requiring an ';' ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch eliminates those warnings referenced below.
They are sometimes associated with an obscure #define.
We'll also corrrect one header file function prototype
so it will aggree with the actual function definition.
Reference(s):
top.c: In function 'adj_geometry':
top.c:1874:20: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
1874 | if (Screen_cols < DOUBLE_limit) Curwin->rc.double_up = 0;
| ^
top.c: In function 'zap_fieldstab':
top.c:2359:26: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
2359 | if (wtab[EU_CPN].wmin < digits) {
| ^
top.c:2365:26: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
2365 | if (wtab[EU_NMA].wmin < digits) {
| ^
top.c: In function 'keys_summary':
top.c:5128:45: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
5128 | if (w->rc.double_up && Screen_cols < DOUBLE_limit) {
| ^
top.c: In function 'sum_tics':
top.c:5605:22: warning: unused variable 'num_syst' [-Wunused-variable]
5605 | int ix, num_user, num_syst;
| ^~~~~~~~
top.c:5605:12: warning: unused variable 'num_user' [-Wunused-variable]
5605 | int ix, num_user, num_syst;
| ^~~~~~~~
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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):
. -7/24/21, introduced new focus toggle
commit 3e922e671d
. 09/23/21, ensure focused tasks stay focused
commit 69978e3650
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the commit referenced below, I fixed what I thought
was all the top 'truncation' warnings. For that commit
I had been using CFLAGS='-ggdb -Wall'. However, if one
uses just a vanilla './configure', then a hidden extra
warning will surface. This patch will finally kill it.
[ thanks a bunch gcc - we love this kind of behavior ]
Reference(s):
. 01/08/22, original warning fix
commit 44ca06f1a0
Signed-off-by: Jim Warner <james.warner@comcast.net>
