By eliminating the call to 'fmtmk', the 'utf8_justify'
function could more easily be used in libproc someday.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Gosh, all this time we used indents of 4 spaces, not 3
spaces which were always the top standard indentation.
[ and we made our 'utf8_embody' a little more robust ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The top man page was changed back on 10/20/15, in that
commit shown below. There, freelists.org was suggested
as the bug reports recipient. But, the program was not
changed from the original Debian bug reports approach.
Reference(s):
commit b1f7b2a509
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch better exploits short-circuit evaluation in
two 'if' tests. In every case, the 1st of 2 conditions
in each 'if' test must take place but it always proves
true with each iteration for 1 of the 'if' statements.
Thus, the 2nd condition will have to be evaluated too.
By reordering 2 tests in each 'if', we can ensure that
the 2nd condition will then be tested much less often.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Upon reflection, there was absolutely no justification
for that call to strlen() which was then followed by a
call to snprintf(). The latter provides this needed #.
[ also make that 'delta' value a little more visible ]
[ instead of hiding it at the end of a its code line ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that top can properly handle translated multi-byte
strings I've been reviewing translated efforts so far,
and weighing output against related translation hints.
In one case, a translation hint has not kept pace with
the current program state. In addition, that same hint
could be expanded to suggest translation alternatives.
[ frankly I never expected the translators to tackle ]
[ some of those 'special' strings. the task appeared ]
[ just too daunting. but they have done a great job! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Before top was modified to exploit the new <pids> api,
there was protection in that task_show() makeVAR macro
to avoid multiple evaluation of this macro's argument.
But, in that commit referenced below, such a safeguard
was lost. This commit simply restores proper behavior.
Reference(s);
. offending change
commit 77dc22b910
Signed-off-by: Jim Warner <james.warner@comcast.net>
Well, for some strange unknown reason it happened in a
commit referenced below. But this patch reverts it and
puts this newlib scale_mem on par with the master guy.
[ a little more research reveals that it should have ]
[ been reverted in the 2nd commit shown. that's when ]
[ types were fixed after XTRA_PROCPS_DEBUG was used. ]
Reference(s):
. when 'unsigned' qualifier lost
commit 911083bf76
. when 'unsigned' qualifier not restored
commit 105058ae2d
. when XTRA_PROCPS_DEBUG validation introduced
commit e3270d463d
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the help of our Swedish translator, hopefully the
final buglet has now been vanquished in the multi-byte
translation support. This one was a real nasty bugger.
Although it didn't occur with every terminal emulator,
occasionally random text lines were being chopped off.
As it turns out, those terminals were blameless. There
were two separate places in top's show_special routine
where potential multi-byte sequences were inadequately
addressed. Solution: exploit existing utf-8 functions.
[ it also became apparent that the translation hints ]
[ in the top_nls module were deficient. so a special ]
[ caution was added regarding the final line of txt. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Unlike the insp_mkrow_raw function the insp_mkrow_utf8
routine is not equipped to print non-ctl, non-printing
characters like '<7f>'. However, technically that very
value currently slips through the cracks. So with this
patch top will now print a space in the unlikely event
a character with the value of 127 is ever encountered.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The ps program generally supports multi-byte sequences
in strings representing user and group names. However,
should a multi-byte sequence span the maximum width of
a column, the '+' inserted by ps to signify truncation
will corrupt that sequence, misaligning the text line.
Unfortunately, there's insufficient info returned from
the escape_str function (who calls escape_str_utf8) to
provide a robust response. So, this commit will revert
to the old standby of displaying a number when the '+'
character would've corrupted that multi-byte sequence.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since all the necessary utf-8 plumbing is now in place
this commit will extend multi-byte support to user and
group names. Now top will be on a par with the ps guy.
[ plus, it's also my way of showing appreciation for ]
[ all those investments silently made by translators ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Translatable column headers are supposed to be limited
to no more than 7 characters, even though some columns
are wider than that or even variable width. That value
of 7 is dictated by the Fields Management screen which
will otherwise truncate a column header longer than 7.
Our new utf-8 support did not adequately deal with the
potential need for truncation of column headers should
that limit of 7 be exceeded. This patch corrects that.
[ a few comments were also tweaked just a little bit ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous commit implemented multi-byte support for
the basic top user interaction and display provisions.
This commit completes multi-byte support by addressing
that 'Inspect Other Output' feature (the 'Y' command).
Few people probably exploit this very powerful feature
which allows the perusing of any file or piped output.
And even if nobody uses 'Y', someone will stumble over
it on the help screen and try it out. Assuming top was
not built with INSP_OFFDEMO defined, they'll end up on
the screen our translators have faithfully translated.
Without this patch, such a screen would display with a
bunch of 'unprintable' characters which will then show
in the standard (less-like) way as: '^A', '<C3>', etc.
In other words, those poor screens will be a big mess!
[ this program can even display an executable binary ]
[ while at that same time supporting Find/Find Next. ]
[ imagine, a file with no guarantee of real strings! ]
[ just try a Find using less with such binary files. ]
With this commit, the translated 'Y' demo screens will
now be properly shown, providing no invalid multi-byte
characters have been detected. Should that be the case
then they'll be displayed in that less-like way above.
And, if users go on to fully exploit this 'Y' command,
there is a good chance that a file or pipe might yield
output in a utf-8 multi-byte form. Should that be true
such output will thus be handled appropriately by top.
[ in many respects, this change was more challenging ]
[ than the basic support within the previous commit. ]
[ story of my life: least used = most effort needed. ]
Many thanks to our procps-ng translators which enabled
a proper test of these changed 'Y' command provisions:
. Vietnamese: Trần Ngọc Quân
. Polish: Jakub Bogusz
. German: Mario Blättermann
. French: Frédéric Marchal, Stéphane Aulery
[ and my sincerest apologies too, for my negligence! ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
When this project first began implementing translation
support nearly 6 years ago, we overcame many 'gettext'
obstacles and limitations. And, of course, there were
not any actual translations at the time so our testing
was quite limited plus, in many cases, only simulated.
None of that, however, can justify or excuse the total
lack of attention to top's approach to NLS, especially
since some actual translations have existed for years.
When the issue referenced below was raised, I suffered
immediate feelings of anxiety, doubt and pending doom.
This was mostly because top strives to avoid line wrap
at all costs and that did not bode well for multi-byte
translated strings, using several bytes per character.
I was also concerned over possible performance impact,
assuming it was even possible to properly handle utf8.
But, after wrestling with the problem for several days
those initial feelings have now been replaced by guilt
over any trouble I initially caused those translators.
One can only imagine how frustrating it must have been
after the translation effort to then see top display a
misaligned column header and fields management page or
truncated screens like those of help or color mapping.
------------------------------------------------------
Ok, with that off my chest let's review these changes,
now that top properly handles UTF8 multi-byte strings.
. Performance - virtually all of this newly added cost
for multi-byte support is incurred during interactions
with the user. So, performance is not really an issue.
The one occasion when performance is impacted is found
during 'summary_show()' processing, due to an addition
of one new call to 'utf8_delta()' in 'show_special()'.
. Extra Wide Characters - I have not yet and may never
figure out a way to support languages like zh_CN where
the characters can be wider than most other languages.
. Translated User Name - at some future point we could
implement translation of user names. But as the author
of the issue acknowledged such names are non-standard.
Thus task display still incurs no new multi-byte costs
beyond those already incurred in that escape.c module.
For raising the issue I extend my sincerest thanks to:
Göran Uddeborg
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'N_fmt' and 'N_txt' macros are interchangeable and
just highlight the 2 str types found in Norm_nlstable.
The change in this patch (strictly cosmetic) was found
during the coding for what will be the next 2 commits.
It has not been squashed into either of those so as to
not muddy up the waters for what was a major refactor.
Signed-off-by: Jim Warner <james.warner@comcast.net>
. ensure whitespace exists between the code & comments
[ changing txt slightly keeps right margin alignment ]
. strive for more consistency with some comment styles
[ don't use C '/*' style where C++ '//' style exists ]
. removed the instance of double space in 1 assignment
[ still striving for consistency in whitespace usage ]
. fixed comment relating to number of 'derived fields'
[ the <meminfo> api recently added one new such enum ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just rearranges 1 item in the stacks_extent
struct to make it equivalent to all the other modules.
Signed-off-by: Jim Warner <james.warner@comcast.net>
As an oversight, delta values for SWAP amounts weren't
included in the <meminfo> API. Since any runtime costs
of including them only amount to slightly more storage
this commit will simply correct the earlier oversight.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The disk partition format translation hint, the actual text and the
printf statements were all diagreeing with each other. This meant
the disk partition output from vmstat was a mess.
Now all the titles and values line up and everything is right-aligned
which looks better than some half-hearted attempt at center-aligned
for titles and right-aligned for values.
Thanks to @goeran for the heads-up in #69
When supplying the -p command to uptime, it does not display any
sections where the value is less than 1; however, after a reboot, this
causes the command to just output "up". Showing 0 minutes when the
system has been up for less than a minute makes it clear a reboot just
occurred.
References:
commit 325d68b7c3
Signed-off-by: Craig Small <csmall@enc.com.au>
read huge informations at once as otherwise all files below
/proc/sys, not using the seq_file API at the kernel side,
will return EOF on a second read.
Signed-off-by: Werner Fink <werner@suse.de>
Until this patch, top falsely assumed that there would
always be some (small) amount of physical memory after
subtracting 'used' and 'available' from the total. But
as the issue referenced below attests, a sum of 'used'
and 'available' might exceed that total memory amount.
I'm not sure if this is a problem with our calculation
of the 'used' amount, a flaw in the kernel 'available'
algorithms or some other reason I cannot even imagine.
Anyway, this patch protects against such a contingency
through the following single line addition of new code
. if (pct_used + pct_misc > 100.0 || pct_misc < 0) ...
The check for less than zero is not actually necessary
as long as the source numbers remain unsigned. However
should they ever become signed, we'll have protection.
[ Most of the changes in this commit simply separate ]
[ a variable's definition from its associated logic. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/64
Signed-off-by: Jim Warner <james.warner@comcast.net>
For the past 3 years top has fully honored that locale
LC_NUMERIC setting which impacts his refresh interval.
For the past nearly 5 years top has saved that refresh
value in a locale independent form in his config file.
With this commit we'll intentionally break top so that
a comma or period will be accepted for the radix point
regardless of what that LC_NUMERIC may have suggested.
The current locale LC_NUMERIC will, however, determine
how the delay interval is displayed in the 'd' prompt.
[ This position is better than the approach employed ]
[ by those coreutils 'sleep' and 'timeout' programs. ]
[ Both claim to permit floating point arguments. But ]
[ neither one will accept the comma separator should ]
[ the locale be a country that in fact uses a comma. ]
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/50
Prototyped by: Jan Rybar <jrybar@redhat.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
There was a time when the PROCPS_PIDS_noop represented
the highest valued enumerator. Therefore if one wished
to prime an array consisting of pids_result structures
with this specific item a loop would have been needed.
Now that this enum is the first one, with the value of
zero, we can avoid avoid such a loop with just calloc.
But just in case, we'll use an 'if' to guarantee zero.
[ and the nice thing is, since the value is known at ]
[ compile time, that 'if' test plus subordinate loop ]
[ can be discarded by the compiler as long as it's 0 ]
Reference(s):
. <pids> introduced (PIDS_noop > 0)
commit 7e6a371d8a
. top employs PIDS_noop at 'new' time
commit f1bd82ff07
. <pids> relocated PIDS_noop (PIDS_noop == 0)
commit e7585992d9
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ok, I admit it. I'm now tired of cleaning up after me.
This is the 3rd related tweak after that '-1' argument
was originally introduced. And with this patch we will
once again properly honor the '-o' and '-u|U' switches
without a need to be followed by an additional switch.
[ one can follow my unfortunate trail of alterations ]
[ beginning with my most recent fix referenced below ]
Reference(s):
commit e3bad0687d
Signed-off-by: Jim Warner <james.warner@comcast.net>
Awhile back, that former QUICK_THREADS #define evolved
into the development (only) FALSE_THREADS which can be
used to ensure a 'duplicate ENUM' convention is output
when certain string fields can't be easily duplicated.
Unfortunately, that original implementation was marred
with zeros being displayed for /proc/$$/meminfo fields
in all the child threads for a multi-threaded process.
So this commit corrects that zero memory field buglet.
Reference(s):
. QUICK_THREADS becomes FALSE_THREADS
commit c546d9dd44
Signed-off-by: Jim Warner <james.warner@comcast.net>
That preceding commit corrected a little mismanagement
regarding the MEMINFO_MEM_CACHED enumerator, which was
used in the following programs: free, top plus vmstat.
This patch simply adapts those programs to use the new
MEMINFO_MEM_CACHED_ALL enumerator, which reflects both
the 'Cached' plus 'SReclaimable' values they expected.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The <meminfo> module attempted to duplicate the former
sysinfo memory calculations wherein 'SReclaimable' was
added to 'Cached' for the 'kb_main_cached' equivalent.
But, this original approach was wrong for two reasons.
1. The addition occurred too late to impact the 'USED'
calculation which could then cause an underflow in the
top memory display if 'SReclaimable' was heavily used.
2. In changing the actual /proc/meminfo 'Cached' value
it meant that users could not rely on that proc(5) man
page when interpreting the MEMINFO_MEM_CACHED results.
So this commit adds a new enumerator for the inclusive
cached amount plus repositions the calculation so that
a MEMINFO_MEM_USED result will exclude 'SReclaimable'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the introduction of a new '1' command line toggle
I have gone and broken a provision of the '-p' command
line switch (pids monitoring). Multiple pids could not
be specified through the use of comma delimited lists.
Thus, this commit simply corrects that newly added bug
which was born in the 'adjustment' commit shown below.
Reference(s):
. adjustment to '-1' implementation
commit 3e5c950a5e
Signed-off-by: Jim Warner <james.warner@comcast.net>
as well do not open /proc/sys files if only the names of the
system control names of the kernel parameters should be shown.
Avoid leaking tmpname in case of a pattern mismatch.
Signed-off-by: Werner Fink <werner@suse.de>
This was supposed to be just a cherry-pick of the referenced
commit. However there were two problems:
1. kill code was moved out to its own file
2. strtosig() had a latent bug where signal numbers were not
converted to names.
Original note:
kill -lHUP would work correctly, but kill -l HUP would not.
The list option in kill was hit by a quirk of getopt_long where an
option with an optional argument would not attempt to get the argument
beyond the space, even though a mandatory argument would do that.
The fix is a kludge to scan to the next argument and if it looks
like something we can use, use it. Lucky for us, the list option is
one where parsing can stop immediately.
Thanks to Brian Vandenberg for the way forward.
References:
http://stackoverflow.com/questions/1052746/getopt-does-not-parse-optional-arguments-to-parametershttps://bugs.debian.org/854407
commit 537cea324b121f54744369425332c256aa84a181
There exists the possibility that a 'putp' call can be
issued before the 'setupterm' invocation has occurred,
as is reflected in a bugzilla report referenced below.
Strangely, such a SEGV isn't always triggered as logic
would suggest it ought to be. I experienced a fault in
these environments with the associated curses version:
. archlinux, procps-ng 3.3.12, ncurses 6.0.20170429
. fedora-25, procps-ng 3.3.10, ncurses 6.0.20160709
. opensuse-42.2, procps-ng 3.3.9, ncurses 5.9.20140201
. gentoo, procps-ng 3.3.12, ncurses 6.0.20150808
. slackw-14.2, procps-ng 3.3.12, ncurses 6.0.20160910
Whereas under these environments there was no problem:
. ubuntu-17.04, procps-ng 3.3.12, ncurses 6.0.20160625
. debian-test, procps-ng 3.3.12, ncurses 6.0.20161126
. mageia-5.1, procps-ng 3.3.9, ncurses 5.9.20140323
[ as an aside, the expected result in the bug report ]
[ is incorrect and should mention the '1' parameter. ]
[ however, until release 3.3.13 when the '1' becomes ]
[ a valid switch, numbers are not detected when used ]
[ with any switch which doesn't require an argument. ]
[ you're welcome to treat that as a separate bugglet ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1450429
Signed-off-by: Jim Warner <james.warner@comcast.net>
In response to that suggestion referenced below, these
changes allow display of task/thread level NUMA nodes.
Currently, only the 'top' program offers any NUMA type
support and it is limited to the Summary Area display.
With this commit both the 'top' and 'ps' programs will
be able to display NUMA nodes associated with threads.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/58
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]
proc/stat.c: In function 'stat_derive_unique':
proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type]
ps/parser.c: In function 'arg_type':
ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
lib/signals.c: In function 'strtosig':
lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
slabtop.c: In function 'print_summary':
slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable]
watch.c: In function 'process_ansi':
watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
Signed-off-by: Jim Warner <james.warner@comcast.net>
When those standardized 'derived' TIC enumerators were
introduced, a problem with potential DELTA distortions
was also introduced when toggling cpus offline/online.
It has always been true that the 1st (summary) line in
/proc/stat will experience a decrease in total tics if
a new cpu is brought online. Such decreases are mostly
due to reductions in 'idle' and 'iowait' tics. Exactly
why such a counterintuitive phenomenon should occur is
a mystery, but this has been acknowledged in proc.txt.
A separate potential distortion arises with individual
cpus. And, here it extends to both bringing processors
online plus taking them offline too. When that happens
the order of the cpus array tracking is upset, placing
the 'new' values in some other processor's array slot.
But even if we were to occupy the same slot, the issue
regarding reductions in 'idle' & 'iowait' still apply.
In all cases, when a DELTA field was found to be minus
it was forced to zero via the 'TICsetH' macro. However
the 'derived' calculations are subject to new forms of
distortion with their own DELTA values. For example we
could find DELTA_SUM_USER + DELTA_SUM_SYSTEM exceeding
DELTA_SUM_TOTAL, an illogical/inappropriate condition.
So this commit moves former protections for individual
cpus to the stat_derive_unique() function and modifies
it to also extend protections to the 'derived' values.
In the process we now protect the cpu 'summary' counts
which were unfortunately previously overlooked (oops).
Reference(s):
. 'derived' types introduced
commit 2c86c4984a
This program has always tried to maintain an extermely
robust command line parsing procedure, far more robust
that what's available with the getopt stuff. But, with
the introduction of our first numeric switch it should
have been made even more robust than, in fact, it was.
This commit will now accomplish such a desirable goal.
Reference(s):
. added '1' command line switch
commit 5e708c5db7
Signed-off-by: Jim Warner <james.warner@comcast.net>
