procps 3.3.17 the c option changed the command/args field
to cmd but this got removed as part of newlib
Functionality is back in with a test case.
References:
https://bugs.debian.org/1026326
Signed-off-by: Craig Small <csmall@dropbear.xyz>
The man page said it cannot show changes to comm, such as when you
use prctl(). In fact, ps can see this. The args field may not change
because its due to the path of the executable but comm can.
The field comm no longer shows defunct for zombie processes, use the
state field for this as it could be obscured if not the last
column anyhow.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
When the skill program was ported to the new API the code to filter
on PID, used by the -p option, was missed. It is now restored.
References:
https://bugs.debian.org/1025915
While ps used the correct type for PIDS_VM_RSS the test
did not. For some reason this only appeared to be an issue
for s390x
References:
https://bugs.debian.org/1025495
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Put the man-po pot file under version control like its po/*.pot sibling.
Makefile now auto-matically generates the list of man pages as they are
in a single directory. There were some missing!
pot file target is dependent on the untranslated man pages
When downloading from translation project, run po4a to sync the new
po files correctly.
Downloaded man po files from translation project and synched.
Thanks to @gorean for the info
References:
procps-ng/procps#258
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Commit c8384e682c ("pgrep: add pwait") changed from the old i_am_pkill
logic, but mistakenly missed a break in the pkill case. This results in
showing -e/--echo twice when running `pkill -h'.
Signed-off-by: Chris Down <chris@chrisdown.name>
Replace AC_CHECK_FUNC by AC_CHECK_FUNCS otherwise HAVE_PIDFD_OPEN will
never be defined resulting in the following build failure if pidfd_open
is available but __NR_pidfd_open is not available:
pgrep.c: In function 'pidfd_open':
pgrep.c:748:17: error: '__NR_pidfd_open' undeclared (first use in this function); did you mean 'pidfd_open'?
748 | return syscall(__NR_pidfd_open, pid, flags);
| ^~~~~~~~~~~~~~~
| pidfd_open
This build failure is raised since the addition of pwait in version
3.3.17 and
c8384e682c
Fixes:
- http://autobuild.buildroot.org/results/f23a5156e641b2ebdd673973dec0f9c87760c688
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Thanks to @kabe-gl for this patch.
w command shows ????? for LOGIN@ column when compiled on 32bit environment with -D_TIME_BITS=64.
References:
#256
Signed-off-by: Craig Small <csmall@dropbear.xyz>
Just as our library was made responsive to a potential
missing 'core id', the top program should also change.
That's because he has his own PRETENDECORE #define and
if that was activated on a platform without 'core id',
the 'CpP' notations would have otherwise been omitted.
Reference(s):
. Oct, 2022 - library fix for missing 'core id'
commit b89e3230b2
Signed-off-by: Jim Warner <james.warner@comcast.net>
Tracking what we do to the library so the N:N:N version strings are
updated. This is just a NEWS item for previous commit.
References:
commit b89e3230b2
______________________________ original newlib message
----------------------------------- ( minus git hash )
When long command line options were introduced, in the
patch shown below, the string associated with the enum
'WRONG_switch_fmt' became obsolete. However, that enum
and its string were never removed. Well, now they are.
Reference(s):
. Sep, 2021 - getopt and long cmdline options
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
When support for graphs was refactored, in that commit
referenced below, the logic for our 'MEMGRAPH_OLD' was
lost while the #define itself remained in the .h file.
Faced with deleting the #define or restoring the logic
I chose the latter. Thus, if one wanted to be reminded
how overstated 'used' memory once was, it can be done.
Reference(s):
. Sep, 2022 - refactored graph support
commit 2d5b51d1a2
Signed-off-by: Jim Warner <james.warner@comcast.net>
When long command line options were introduced, in the
patch shown below, the string associated with the enum
'WRONG_switch_fmt' became obsolete. However, that enum
and its string were never removed. Well, now they are.
Reference(s):
. Sep, 2021 - getopt and long cmdline options
commit c91b371485
Signed-off-by: Jim Warner <james.warner@comcast.net>
In that commit referenced below, I removed the command
line help text from any translation so the TP wouldn't
delay our 4.0.1 release any further. In looking to the
future, when we might be able to reverse that, I found
gettext tools blocking use of the compile conditional.
They are too primitive for the original approach so we
must modify that exclusion mechanism hack accordingly.
____________________________excerpted program comments
The provision excluding some strings is intended to be
used very sparingly. It exists in case we collide with
some translation project person in a position to delay
a future release over his or her personal preferences.
If it's ever enabled, it will produce a fatal compiler
error as our only option since those gettext tools are
far too primitive to be influenced with a conditional.
They always ignore a '_X()' macro no matter its state.
Reference(s):
commit 8a368bfb05
Signed-off-by: Jim Warner <james.warner@comcast.net>
The provision excluding some strings is intended to be
used very sparingly. It exists in case we collide with
some translation project person in a position to delay
a future release over his or her personal preferences.
(it's currently used only on v4.0.1 command line help)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Prior to this commit, when the '5' key was struck, top
would check for the presence of e-cores just one time.
That meant if a some cpu was brought online, and it in
turn exposed a new e-core after top has started, users
needed a top restart to activate the new '5' feature.
So, now we'll check for any e-cores with each '5' key.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Wow, after this we'll eliminate one 'jmp' instruction!
[ plus we can also save a single precious whitespace ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit that changed configure.ac was supposed to check for when
someone removes ncurses using the flag --without-ncurses
Unfortunately the change didn't check if the user was specifying
--without or --with meaning if they didn use --with-ncurses the
configure script would error out.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
commit 8128641814procps-ng/procps#251
I sure hope we won't disappoint the library with these
changes since we're only exploiting one of the two new
enumerators that the immediately prior patch provided.
Now top will be able to offer a visual clue as to each
cpu (thread actually) core association. Is it a P-core
offering multiple threads or a single threaded E-core.
We'll accomplish this feat with a subtle change to the
states portion ('t' toggle) of the summary area. Where
before processors were represented as 'Cpu', they will
now be displayed as 'CpP' (P-core) and 'CpE' (E-core).
[ assuming that new '5' command toggle has been used ]
There are also new provisions for filtering those cpus
by their core type association via the new '5' toggle.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With Intel's 12th generation Alder Lake processors now
providing two distinct types of core, it would be nice
if the library offered some sort of clue to core type.
Well, with this patch it does. We'll have 2 additional
enumerators. One deals with the cpu's core association
and the other provides the type of that core (P or E).
[ now, all we need is for some program to exploit it ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
______________________________ original newlib message
----------------------------------- ( minus git hash )
When that 'Bottom' window was being finalized, an enum
of BREAK_screen was added to the Frames_signal values.
This was done so some full screen replacement function
could flag the need for that bottom window to go away.
Around that same time, top was made more responsive to
keyboard input so that residual portions of a previous
bottom window would not linger until the next refresh.
This happened if going from a larger (^N, environment)
bottom window to some smaller window (^P, namespaces).
The combined effect of these changes was to create the
potential race condition this commit addresses. If the
user encountered a SIGWINCH while on any of those full
screen replacement displays (help, fields mgmt, etc.),
endless redraws would occur. A ^C was the only option.
Henceforth we will protect against any redraw loops by
clearing Frames_signal each time a redraw is required.
[ along the way, we'll make the 'q' key work on that ]
t secondary 'windows' help screen as it should, even ]
[ though it is not documented on that screen itself. ]
Reference(s):
. May, 2022 - more responsive to keyboard input
commit ........................................
. May, 2022 - maybe force the bottom window off
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
______________________________ original newlib message
----------------------------------- ( minus git hash )
Darn, after testing on some older, out of date distros
I was embarrassed to find some awful code I created in
the commit shown below. I was rewarded with some 'nan'
floating point values and 'inf' computational results.
Reference(s);
. a missed opportunity to repent
commit ........................................
. true source of my original sin
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'unrelated' note reflected in the original message
doesn't apply since we already used that correct name.
______________________________ original newlib message
If one per line display of Mem/Swap data was forced by
this #define, screen width was not fully exploited for
graph mode. Rather, those graphs were scaled just like
they would be if aligned with a nonexistent separator.
With this commit, those graphs will expand to fill the
screen width (or be limited by the maximum of '100' ).
[ and in unrelated news a variable used in do_memory ]
[ was changed for consistency. it doesn't affect the ]
[ the results since a part1 of swap was always zero. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
______________________________ original newlib message
This patch introduces a new #define TOG4_MEM_FIX which
serves to turn off the new feature it also implements.
The feature, on by default, provides a flexible memory
graph approach which strives to always keep its visual
separator in alignment with cpu separators seen above.
Below is a summary of the algorithm implementing this:
1) First, ascertain the widest graph which corresponds
to the largest number of cpu graphs but doesn't exceed
maximum allowable graph width (i.e. GRAPH_length_max).
2) Next, apply that to the graphed 'Mem' portion which
is likely to remain entirely visible. However, it will
grow or shrink depending on total adjacent cpu graphs.
3) Last, the same width is used for the 'Swap' portion
but that graph is considered sacrificial and very well
could be truncated depending on the width of a screen.
[ along the way, when the cpu graphs revert to their ]
[ abbreviated form, the memory graphs will also show ]
[ an abbreviated prefix. in this way the widths will ]
[ also be maximized, reducing potential distortions. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
______________________________ original newlib message
This commit will change some comments, adjust a little
whitespace but mostly rename some #define identifiers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
______________________________ original newlib message
When displaying detailed memory statistics two abreast
data for the lines are less than those for cpus. So we
can exploit such a difference to provide a distinctive
separator. This may help separating cpu & memory data.
[ in truth, this happened before this patch. what we ]
[ are doing now is polishing that accidental feature ]
[ and placing it under the control of a conditional. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
______________________________ original newlib message
When displaying detailed cpu statistics, as opposed to
those scalable graphs, only two per line can be shown.
Therefore, if we are showing a detail version, our '4'
toggle must prematurely revert to single mode display.
Conversely, the 't' toggle must also turn off that '4'
toggle rather than try to print more than 2 abreast if
we're currently executing in detailed statistics mode.
Signed-off-by: Jim Warner <james.warner@comcast.net>
