Jim Warner [Mon, 1 Oct 2018 05:00:00 +0000 (00:00 -0500)]
top: enable alternate '+' placement with collapsed pid
Currently, except for tasks that have no parents, when
a process' children are collapsed the '+' indicator is
shown in the first position within that COMMAND field.
This commit simply provides for indenting the '+' char
so it displays next to that program name/command line.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Tue, 18 Sep 2018 05:00:00 +0000 (00:00 -0500)]
top: plug a minor hole in the vertical scrolling logic
In that commit referenced below, a few edge cases were
addressed regarding vertical positioning involving any
'hidden' tasks. But, 2 additional edge cases remained.
In a running top, if the user employed 'other filters'
(o/O) or 'user filters' (u/U) proper vertical position
was not ensured. And, while this could be easily fixed
by striking the home/end or up/down arrow keys, it was
very poor etiquette to shift this burden to the users.
So, this patch plugs that gap, automating the process.
Jim Warner [Sat, 1 Sep 2018 05:00:00 +0000 (00:00 -0500)]
top: eliminated the use of that 'procps.h' header file
That prior patch set the stage for eliminating the use
of that 'procps.h' header, while retaining support for
a ./configure -DXTRA_PROCPS_DEBUG' during development.
This commit just eliminates top's use of 'procps.h' in
favor of a separate include for needed newlib headers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sat, 1 Sep 2018 05:00:00 +0000 (00:00 -0500)]
library: refactor the XTRA_PROCPS_DEBUG implementation
If we ever were to eliminate the procps.h header file,
as discussed in the thread referenced below, then that
would impair the current XTRA_PROCPS_DEBUG provisions.
The only remaining way to verify result types would be
to explicitly include that <proc/xtra-procps-debug.h>.
So, this commit will once again enable the ./configure
provision for defining the -DXTRA_PROCPS_DEBUG option.
Jim Warner [Wed, 22 Aug 2018 05:00:00 +0000 (00:00 -0500)]
top: a tweak to the forest view collapsed code (again)
From the outset, top has tried to provide some minimal
garbage collection in support of forest view collapse.
For example, with every 'v' keystroke, a check is made
of the currently targeted pids. If all were negative,
which means expanded, that Hide_pid array was emptied.
Recently, yet another efficiency was added wherein the
continuing scan for a targeted pid was terminated when
a match was found. But, one more inefficiency existed.
When a task which was subject to collapse under forest
view mode has disappeared (ended), repeatedly scanning
for such a pid with each iteration makes little sense.
So this commit will negate such targeted pids and thus
avoid scanning every current task looking for a match.
Then, if 'v' is ever stuck at some point in the future
there will be a chance to empty that Hide_pid[] array.
[ hopefully this will be a final tweak of the forest ]
[ view collapse stuff, but cross your fingers anyway ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 9 Aug 2018 05:00:00 +0000 (00:00 -0500)]
top: speed up the collapsed children forest view logic
In forest view mode, once a collapsible parent process
and all of its children (if any) have been identified,
there is no longer a need to scan the remaining tasks.
So this patch will just force a new scan for any other
'Hide_pid' entries which might remain to be identified
after a targeted parent has been completely processed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 1 Aug 2018 05:00:00 +0000 (00:00 -0500)]
top: eliminate all of that 'relative enumerator' bloat
The top program has always specified the maximum stack
depth at 'new' time. Then, in those stacks the minimum
number of result structures were used for representing
only fields actually being displayed in the 4 windows.
That, however, complicated all subsequent access since
each field's enumerator then had to be translated into
a relative position when interacting with the library.
This was accomplished by that Fieldstab 'erel' member.
So this patch eliminates an extra level of indirection
by fully exploiting the existing maximum sized stacks.
Now, the enumerators that top uses to represent fields
also represent their relative positions in each stack.
[ for fields not actually displayed, the position in ]
[ a stack is represented by the 'PIDS_extra' struct. ]
[ thus, there isn't any real library costs for those ]
[ enumerators/fields which aren't currently visible. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Craig Small [Wed, 8 Aug 2018 10:13:58 +0000 (20:13 +1000)]
docs: Update ps.1 to warn about command name length
Previous versions of ps used to only match on the first 15 characters
because that's what the kernel used to provide. Newer kernels have a
longer length for this field so procps has been updated to suit.
Jim Warner [Wed, 25 Jul 2018 05:00:00 +0000 (00:00 -0500)]
top: existing 'Inspect' pipe feature now more flexible
Currently, it isn't possible to establish an 'Inspect'
pipe that relies on SIGINT to end. That's because this
signal will also end the parent process (top) as well.
So this patch will temporarily ignore that signal when
processing any 'Inspect' pipe, allowing one like this:
Upon startup there exists the potential for some minor
memory leakage should some rcfile 'Inspect' entries be
invalid. By delaying any malloc/strdup until after the
entries are completely validated we will prevent that.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 18 Jul 2018 05:00:00 +0000 (00:00 -0500)]
top: ensure collapsed children cpu reported accurately
Parent tasks with collapsed children should have their
cpu reflect any unseen tasks only under the following:
1) When built without TREE_VCPUOFF having been defined
2) Exclusively when 'Show_FOREST' display mode was set
3) And only under the current window when in alternate
display mode (except if TREE_VWINALL has been defined)
So, this commit just ensures these objectives are met.
Reference(s):
. issue that began odyssey
https://gitlab.com/procps-ng/procps/issues/99
. original cpu implementation
commit 7c7903e50dff8719408b2a95d75f94ec1407aff7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Tue, 17 Jul 2018 05:00:00 +0000 (00:00 -0500)]
top: make the TREE_VCPUOFF define a tad more inclusive
While this newlib branch did not suffer that SEGV fate
the master branch did with children's %CPU accounting,
it didn't manage the 'TREE_VCPUOFF' #define optimally.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Tue, 10 Jul 2018 05:00:00 +0000 (00:00 -0500)]
top: '^V' is now 'v' (collapse/expand children toggle)
Using Ctrl-V for the collapse children key now appears
as a mistake. First, it's too close to that Ctrl-C key
which would prematurely terminate top. Second, a lower
case 'v' was unused and perfectly compliments an upper
case 'V' which is used to toggle 'forest view' itself.
Jim Warner [Wed, 4 Jul 2018 05:00:00 +0000 (00:00 -0500)]
top: some minor renaming, reformatting and rearranging
This commit just addresses these miscellaneous issues:
. make a few pseudo enum's just a tad more descriptive
. always use 'p' for pointers to a 'struct pids_stack'
. add just a little indent to the 'rSv' macro comments
. rearrange section dealing with new library interface
. always match order of local #undef to parent #define
. forest_begin array index usage is now more efficient
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Mon, 25 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: parent total cpu includes collapsed children, pgm
Now, when a parent's children have been collapsed, the
cpu used by those unseen tasks will disappear no more.
Instead such tics will be added to the parent's total.
[ if one wished a return to the 'land of lost tics', ]
[ the '#define TREE_VCPUOFF' directive is available. ]
------------------------------------------------------
Note: With collapsible parents now displaying children
cpu usage, it will eventually be noticed the cpu stats
for the summary area and task areas often vary widely.
It's worth a reminder that for top's summary area each
individual cpu and the cpu summary is limited to 100%,
regardless of how many tics a linux kernel may export.
An individual task is limited to 100% times the number
of threads. But, in no case will cpu usage ever exceed
100% times total number of processors. Such limits are
further reduced under 'Solaris' mode ('I' toggle off).
In this mode, a task cpu usage will never exceed 100%.
These limits will now also apply to collapsed parents.
In addition to those influences, results are subjected
to kernel timer sampling anomalies and the distortions
inherent in a small sample size, made worse by smaller
delay intervals. Often there is just 1 or 2 tics for a
few tasks at smaller intervals such as: 1/10th second.
Anyway, should questions on this subject arise, a good
starting point, beyond the reminders above, is the 1st
link listed below. Those other links were derivatives.
Reference(s):
. from the kernel documentation
https://www.kernel.org/doc/Documentation/cpu-load.txt
. as mentioned in the above kernel documentation
https://lkml.org/lkml/2007/2/12/6
. from above, with many more links on the subject
https://www.boblycat.org/~malc/apc/
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 21 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: a few tweaks for those scrolling (mostly) changes
This patch just addresses some edge cases with respect
to 'unseen' tasks. Given the ability to preserve other
filters in the rcfile, it's entirely possible the very
first task(s) may not be visible at top startup. Also,
when switching between windows ('a'/'w') we should try
to always position its row #1 on some visible process.
Lastly, a window might have *NO* visible tasks at all.
Therefore, protect 'window_hlp' from an infinite loop.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: normalize vertical scrolling for hidden processes
To my knowledge, nobody has ever complained about some
anomalies when scrolling vertically if tasks should be
hidden from view. This can happen with the user filter
('u/U') or other filter ('o/O') features. And although
some tasks are not shown, they still impact scrolling.
This is most apparent when that scroll coordinates msg
is on ('C') & up/down arrow keys used (vs. pgup/pgdn).
Now that we can collapse/expand forked children, there
is a potential for yet more of those hidden processes.
So this commit normalizes vertical scrolling providing
an expected behavior. In other words, the up/down keys
skip the unseen tasks to reposition on a visible task.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: refactor the 'scroll coordinates' message support
This patch is simply preparation for upcoming vertical
scrolling enhancements. With those changes, it will be
impossible to predict what the beginning task position
should be at the time the message is currently issued.
This patch will allow such a message to be shown after
the individual windows' tasks have all been displayed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The issue cited below really dealt with preserving the
'Other filter' criteria in the rcfile. But as an aside
the htop 'F6' feature (collapsed children) was raised.
I took that as an implied challenge and decided to try
implementing a similar feature in top. So, this commit
will now provide a brand new forest view toggle ('^V')
which will be used to collapse/expand forked children.
[ this patch will also lead to additional patches in ]
[ support of more rational vertical scrolling, since ]
[ many more tasks might now be hidden in some window ]
Reference(s):
. where this secondary issue was raised
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: to prepare for collapse, move forest view support
In anticipation of a new collapsible child feature, we
will have to make some forest view variables available
to that 'keys_task()' function. This commit just moves
the forest view logic ahead of tertiary input support.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: 'other filters' saved with config file, pgm logic
Well, after the rearranging and refactoring, all those
active 'other filter' entries for each window will now
be preserved in the user's configuration file via 'W'.
For raising the issue below, thanks to Marco Ippolito.
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: refactored some more peripheral 'inspect' support
These modifications are being made now in anticipation
of some coming 'other filter' config file changes. Our
entries must be written last to the rc file since that
is where the users have been told to 'echo' additions.
Therefore, that 'config_insp' function must be adapted
to anticipate a passed buffer that was already primed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: refactored some of that 'other filtering' support
If we are to support preserving 'other filter' entries
in the rcfile, then the current logic setting up those
osel entries for a WIN_t must be shareable for startup
and when interacting with a user. So, this commit just
repositions this current code in a shareable function.
[ along the way, we give the prior guy a proper name ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: reposition some of that 'other filtering' support
When we get around to saving that 'Other Filter' stuff
in the rcfile, we'll need access to the Fieldstab plus
the justify_pad() function. So this commit repositions
two 'osel' functions in anticipation of adding 1 more.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 20 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: refactor some of that configuration files support
The 'config_file()' function was getting a little long
in the tooth, so this commit simply renames/rearranges
some stuff anticipating 'other filters' in the rcfile.
Signed-off-by: Jim Warner <james.warner@comcast.net>
0121-w: Clamp maxcmd to the MIN/MAX_CMD_WIDTH range.
The current checks allow out-of-range values (for example, if
getenv/atoi returns ~-2GB, maxcmd becomes ~+2GB after the subtraction).
This is not a security problem, none of this is under an attacker's
control.
Check the return value of sscanf() to make sure that all input items are
properly initialized.
In extended mode (x_option), one_proc() loads the values of start and
perms during one iteration of the while loop, and displays them during
one of the following iterations, but start and perms are variables local
to the while loop: move them out of the while loop, to the beginning of
the function.
Also, display a mapping only if cp2 is properly initialized; otherwise
(for example), mappings that do not belong to a selected range are
displayed, and with a NULL mapping name:
If "cp = strrchr(mapbuf_b, '/')" then this function returns, and
otherwise there is no '/' in mapbuf_b and "cp = strchr(mapbuf_b, '/')"
is always false: remove this second block, since it is never entered.
Also, constify a few things in this function.
In the headers, the space was misplaced; for example, "pmap -XX $$"
outputs "VmFlagsMapping" (without a space). Use justify_print() instead
of printf().
There was also an extra space in the output, because vmflags[] (from the
"VmFlags:" line) always ends with a space. Overwriting this last space
with a null byte fixes this misalignment.
vmflags[] is a 27*(2+1)=81 char array, but there are 30 flags now (not
27), and even with 27 flags this was an off-by-one overflow (the kernel
always outputs a flag with "%c%c ", so the last +1 is for a space, not
for the terminating null byte). Protect vmflags[] with a maximum field
width, as in the surrounding sscanf() calls.
0088-pmap: Always check the return value of fgets().
Otherwise "the contents of the array remain unchanged and a null pointer
is returned" or "the array contents are indeterminate and a null pointer
is returned".
0027-skill: Prevent multiple overflows in ENLIST().
First problem: saved_argc was used to calculate the size of the array,
but saved_argc was never initialized. This triggers an immediate heap-
based buffer overflow:
Second problem: saved_argc was not the upper bound anyway, because one
argument can ENLIST() several times (for example, in parse_namespaces())
and overflow the array as well.
Third problem: integer overflow of the size of the array.
No need to "pid_count++;" because "ENLIST(pid," does it already. Right
now this can trigger a heap-based buffer overflow.
Also, remove the unneeded "pid_count = 0;" (it is static, and
skillsnice_parse() is called only once; and the other *_count variables
are not initialized explicitly either).
The memmove() itself does not move the NULL-terminator, because nargs is
decremented first. Copy how skill_sig_option() does it: decrement nargs
last, and remove the "if (nargs - i)" (we are in "while (i < nargs)").
man getline: "If *lineptr is set to NULL and *n is set 0 before the
call, then getline() will allocate a buffer for storing the line. This
buffer should be freed by the user program even if getline() failed."
0020-pidof: Prevent integer overflows with grow_size().
Note: unlike "size" and "omit_size", "path_alloc_size" is not multiplied
by "sizeof(struct el)" but the checks in grow_size() allow for a roughly
100MB path_alloc_size, which should be more than enough for readlink().
Do it explicitly instead of the implicit "longjmp() cannot cause 0 to be
returned. If longjmp() is invoked with a second argument of 0, 1 will be
returned instead."
Otherwise (for example), if the (undocumented) opt_echo is set, but not
opt_long, and not opt_longlong, and not opt_pattern, there is a call to
xstrdup(cmdoutput) but cmdoutput was never initialized:
(the LD_DEBUG is just a trick to fill the initial stack with non-null
bytes, to show that there is uninitialized data from the stack in the
output; here, an address "fcd4 e6bd e47f")
0002-pgrep: Prevent integer overflow of list size.
Not exploitable (not under an attacker's control), but still a potential
non-security problem. Copied, fixed, and used the grow_size() macro from
pidof.c.
Jim Warner [Thu, 7 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: force return to row 1 for thread mode transitions
This program does a good job of policing that vertical
scrolled position, ensuring that total tasks are never
exceeded. However, during transitions from thread mode
to normal task mode (the 'H' toggle) that wasn't true.
And while there was no real harm done, it did make the
use of up/down arrow keys "appear" disabled especially
if that scroll message was not displayed ('C' toggle).
This patch simply forces a return to row #1 whenever a
user toggles that display between thread & task modes.
Signed-off-by: Jim Warner <james.warner@comcast.net>
As it turns out, the very first entry in the 'iokey()'
tinfo_tab was preventing the proper translation of the
simulated PgUp/PgDn keys (ctrl+meta+k/j). Ignoring the
tortured history behind the most recent change to that
entry, this patch restores the previous value and once
again properly translates these particular keystrokes.
Signed-off-by: Jim Warner <james.warner@comcast.net>
0066-ps/sortformat.c: Handle large width in aix_format_parse().
Unlikely to ever happen, since it would imply a very large string, but
better safe than sorry.
---------------------------- adapted for newlib branch
. now uses 'xmalloc' vs. unchecked stdlib 'malloc'
. the member 'need' was removed from 'format_node'
Signed-off-by: Jim Warner <james.warner@comcast.net>
0064-ps/sortformat.c: Double-check chars in verify_short_sort().
To avoid an out-of-bounds access at checkoff[tmp]. The strspn() at the
beginning of the function protects against it already, but double-check
this in case of some future change.
0062-ps/display.c: Always exit from signal_handler().
Right now, "we _exit() anyway" is not always true: for example, the
default action for SIGURG is to ignore the signal, which means that
"kill(getpid(), signo);" does not terminate the process. Call _exit()
explicitly, in this case (rather than exit(), because the terminating
kill() calls do not call the functions registered with atexit() either).
0061-ps/output.c: Always null-terminate outbuf in show_one_proc().
Before "strlen(outbuf)", if one of the pr_*() functions forgot to do it.
This prevents an out-of-bounds read in strlen(), and an out-of-bounds
write in "outbuf[sz] = '\n'". Another solution would be to replace
strlen() with strnlen(), but this is not used anywhere else in the
code-base and may not exist in all libc's.
---------------------------- adapted for newlib branch
. adapted via 'patch' without rejections
Signed-off-by: Jim Warner <james.warner@comcast.net>
0060-ps/output.c: Protect outbuf in various pr_*() functions.
pr_bsdstart(): Replace "strcpy(outbuf," with "snprintf(outbuf, COLWID,"
(which is used in all surrounding functions). (side note: the fact that
many pr_*() functions simply return "snprintf(outbuf, COLWID," justifies
the "amount" checks added to show_one_proc() by the "ps/output.c:
Replace strcpy() with snprintf() in show_one_proc()." patch)
pr_stime(): Check the return value of strftime() (in case of an error,
"the contents of the array are undefined").
help_pr_sig(): Handle the "len < 8" case, otherwise "sig+len-8" may
point outside the sig string.
pr_context(): Handle the empty string case, or else "outbuf[len-1]"
points outside outbuf.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
Signed-off-by: Jim Warner <james.warner@comcast.net>
0059-ps/output.c: Enforce a safe range for max_rightward.
Enforce a maximum max_rightward of OUTBUF_SIZE-1, because it is used in
constructs such as "snprintf(outbuf, max_rightward+1," (we could remove
the extra check at the beginning of forest_helper() now, but we decided
to leave it, as a precaution and reminder).
The minimum max_rightward check is not strictly needed, because it is
unsigned. However, we decided to add it anyway:
- most of the other variables are signed;
- make it visually clear that this case is properly handled;
- ideally, the minimum max_rightward should be 1, not 0 (to prevent
integer overflows such as "max_rightward-1"), but this might change
the behavior/output of ps, so we decided against it, for now.
Instead, we fixed the only function that overflows if max_rightward is
0. Also, enforce the same safe range for max_leftward, although it is
never used throughout the code-base.
---------------------------- adapted for newlib branch
. adapted via 'patch' without rejections
Signed-off-by: Jim Warner <james.warner@comcast.net>
1/ Do not go deeper than the size of forest_prefix[], to prevent a
buffer overflow (sizeof(forest_prefix) is roughly 128K, but the maximum
/proc/sys/kernel/pid_max is 4M). (actually, we go deeper, but we stop
adding bytes to forest_prefix[])
2/ Always null-terminate forest_prefix[] at the current level.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
. a commented out 'debug' line was no longer present
Signed-off-by: Jim Warner <james.warner@comcast.net>
0054-ps/output.c: Fix outbuf overflows in pr_args() etc.
Because there is usually less than OUTBUF_SIZE available at endp.
---------------------------- adapted for newlib branch
. logic is quite different with 'stacks' vs. 'proc_t'
. ps no longer deals with the library 'FILL...' flags
Signed-off-by: Jim Warner <james.warner@comcast.net>
May happen if strlen(src) > INT_MAX for example. This patch prevents
escaped_copy() from increasing maxroom and returning -1 (= number of
bytes consumed in dst).
---------------------------- adapted for newlib branch
. formerly applied to proc/escape.c
. function was moved to ps/output.c
Signed-off-by: Jim Warner <james.warner@comcast.net>
0048-ps/output.c: Make sure all escape*() arguments are safe.
The SECURE_ESCAPE_ARGS() macro solves several potential problems
(although we found no problematic calls to the escape*() functions in
procps's code-base, but had to thoroughly review every call; and this is
library code):
1/ off-by-one overflows if the size of the destination buffer is 0;
2/ buffer overflows if this size (or "maxroom") is negative;
3/ integer overflows (for example, "*maxcells+1");
4/ always null-terminate the destination buffer (unless its size is 0).
---------------------------- adapted for newlib branch
. formerly applied to proc/escape.c
. function was moved to ps/output.c
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 6 Jun 2018 05:00:00 +0000 (00:00 -0500)]
ps: move other initialization code after setREL macros
While the previous patch concerned an essential change
to avoid dereferencing those NULL pointers, this patch
could be considered optional. For consistency, it just
puts all initialization logic after the setREL macros.
[ plus along the way some inter-function spacing was ]
[ standardized with just a single blank line between ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 6 Jun 2018 05:00:00 +0000 (00:00 -0500)]
ps: ensure functions not called prior to setREL macros
Under newlib design, ps must loop though all potential
print functions so as to gather the appropriate enum's
while establishing the 'relative' equivalent. The keys
to the setREL/chkREL macros are a NULL 'outbuf' param.
It's imperative that no other functions be called with
that NULL value. Unfortunately, several instances were
found where this was violated. They are now corrected!
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Tue, 5 Jun 2018 05:00:00 +0000 (00:00 -0500)]
top: provide the means to exploit a 256-color terminal
With the Qualys security audit, we began to harden our
treatment of the top rcfile. In particular, the values
read were checked so as to prevent some malicious user
from editing it in order to achieve an evil objective.
However when it came to colors I was surprised to find
that at least one user edited the rcfile for 256-color
support. Unfortunately, our new checks prevented this.
So this commit will provide the means to exploit those
extra colors with no need to manually edit the rcfile.
projects / procps-ng / log