Much of what was represented in the commit message for
the reference shown below was revisited in this patch.
It also means that the assertion in the last paragraph
of that message will only now be true with LANG unset.
[ and forget all the bullshit about not altering any ]
[ kernel supplied data. sometimes we must to avoid a ]
[ corrupt display due to a string we can not decode. ]
And while this commit still avoids the overhead of the
'mbrtowc', 'wcwidth' 'isprint, & 'iswprint' functions,
we achieve all the benefits with simple table lookups.
Plus such benefits are extended to additional strings.
For example, both PIDS_EXE and PIDS_CMD fields are now
also subject to being 'escaped'. If a program name did
contain multibyte characters, potential truncation may
corrupt it when it's squeezed into a 15/63 byte array.
Now, all future users of this new library only need to
deal with the disparities between string and printable
lengths. Such strings themselves are always printable.
[ the ps program now contains some unnecessary costs ]
[ with the duplicated former 'escape' functions. But ]
[ we retain that copied escape.c code for posterity. ]
[ besides, in a one-shot guy it's of little concern. ]
Note: Proper display of some multibyte strings was not
possible at the linux console. It would seem a concept
of zero length chars (like a 'combining acute accent')
is not recognized. Thus the display becomes corrupted.
But if utf8 decoding is disabled (via LANG=), then all
callers will now see '?', restoring correct alignment.
Reference(s):
. Dec 2020, newlib 'escape' logic refactored
commit a221b9084ae979e6fd073a83e7fbc46c44551f35
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since this master library isn't quite as sophisticated
as the newlib version, this patch will protect against
the possibility of multibyte characters in a program's
name combined with some locale without UTF-8 encoding.
[ it is better to treat the COMMAND column length as ]
[ more than what's actually printed than to have the ]
[ line overflow & corrupt the remaining screen lines ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is intended to bring the master branch into
closer alignment with the newlib branch functionality.
The commit shown below replaced that 'escape_str' with
'escaped_copy' so that the ps program wouldn't execute
some code twice. However, it created a problem for the
top program when the UTF-8 encoding was not available.
Unlike ps who calls the escape functions directly, top
outputs those library provided strings unaltered. That
means there is no workaround (like LANG=) when such an
encoding was unavailable. This, in turn, can lead to a
corrupted display (especially with the linux console).
Now, when a UTF-8 encoding is not available, multibyte
chars are converted to '?', reducing display problems.
[ there's still a potential problem concerning 'cmd' ]
[ should program names contain multibyte characters. ]
[ unlike that newlib branch, this string is not ever ]
[ altered with the '?' char under the master branch. ]
Reference(s);
. Dec 2020, escaoed_copy repleced most escape_str
commit eea5626bb144328eb60e9ea8a29bd5b1f100ecd9
Signed-off-by: Jim Warner <james.warner@comcast.net>
This new library provides callers with pure strings or
string vectors. It is up to those callers to deal with
potential utf8 multibyte characters and any difference
between strlen and the corresponding printable widths.
So, it makes no sense for the library to go to all the
trouble of invoking those rather expensive 'mbrtowc' &
'wcwidth' functions to ultimately yield total 'cells'.
Thus, this patch will eliminate all the code and parms
that are involved with such possible multibyte issues.
[ Along the way we'll lose the ability to substitute ]
[ '?' for an invalid/unprintable multibyte sequence. ]
[ We will, however, replace ctrl chars with the '?'. ]
[ This presents no problem for that ps program since ]
[ it now duplicates all of the original escape code. ]
[ And, we'll no longer be executing that code twice! ]
[ As for the top program, it takes the position that ]
[ it is wrong to alter kernel supplied data. So with ]
[ potential invalid/unprintable stuff, he'll rely on ]
[ terminal emulators to properly handle such issues! ]
[ Besides, even using a proper multibyte string, not ]
[ all terminals generate the proper printable width. ]
[ This is especially true when it comes to an emoji. ]
[ And should callers chose not to be portable to all ]
[ locales by calling setlocale(LC_ALL, ""), they can ]
[ expect to see lots of "?", regardless of what this ]
[ library fixes in a faulty multibyte string anyway. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When any process' command line contains multibyte utf8
characters, two separate display problems could arise.
1. If that COMMAND column is not displayed as the very
last field, then field(s) to the right are misaligned.
2. Even when last, should utf8 string length (not that
display length) exceed allowable screen width, it will
nonetheless suffer from improper premature truncation.
Number 1 is less of a concern since the cmdline column
is likely to always be the last field to be displayed,
if only to enable right and left scrolling provisions.
Number 2 is much more likely to occur, especially with
additional fields which might be shown before COMMAND.
Or, forest view child tasks can yield the same effect.
So, this commit will permit the correct utf8 multibyte
display regardless of field position or string length.
And, we'll bring top into line with the ps program for
additional fields potentially subject to utf8 display.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Form its inception (back in May of 2011), escaped_copy
has always been a flawed function. It does not operate
on 'escaped' strings but instead treats all input as a
regular string incapable of containing utf8 sequences.
As such, it should only be used for strings guaranteed
to NOT embody multibyte characters (like SUPGIDS). For
all other strings, which could contain utf8 stuff, the
correct function should have been that escape_str guy.
So this commit changes nearly every escaped_copy call.
Reference(s):
. May 2011, original escaped_copy (cmdline, cgroup)
commit 7b0fc19e9d28380dc9790615b93bc3653d6d686e
Signed-off-by: Jim Warner <james.warner@comcast.net>
After 'errno' management was standardized, a couple of
fields were added to the <pids> api. Only 1 (PIDS_EXE)
involved dynamic memory and, unfortunately, it did not
conform to that expected normalized ENOMEM convention.
Reference(s):
. Jun 2018, added 'exe' to library
commit ad4269f1189d5a7d68765e291bcfa981b6731c25
. Nov 2017, standardized 'errno' management
commit 06be33b43e5ff3f2658e77ef79441ac2e970cfd7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Under the above #define this commit now also addresses
2 additional possible toe stubbers involving 'select'.
If some readproc.h constants were uncoupled from their
pids.h enumerators a 'make check-lib' will now detect.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The Fieldstab uses the full pids_item enumerator names
but also shows top's cryptic relative enumerator names
as comments. So, this commit will mirror that approach
in task_show, adding full pids_item names as comments.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the ps program is using 'escape_str' for most
of the library's returned strings, this patch tries to
lessen the prospects of executing that function twice.
Our newlib branch has achieved such a goal through the
elimination of nearly all escape.c code. However, here
we avoid API change by trading some 'escape_str' calls
(with wide character overhead) for a slightly extended
'escaped_copy' call (which incurs no multibyte costs).
Note: until we migrate to the newlib version, there is
a remaining call to 'escape_str' which we can't avoid.
Such code involves the 'escape_command' function call.
[ As we prepare for this new (final?) release, there ]
[ were already internal library changes that require ]
[ a new 'revision'. This patch won't impact the API! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When any process' command line contains multibyte utf8
characters, two separate display problems could arise.
1. If that COMMAND column is not displayed as the very
last field, then field(s) to the right are misaligned.
2. Even when last, should utf8 string length (not that
display length) exceed allowable screen width, it will
nonetheless suffer from improper premature truncation.
Number 1 is less of a concern since the cmdline column
is likely to always be the last field to be displayed,
if only to enable right and left scrolling provisions.
Number 2 is much more likely to occur, especially with
additional fields which might be shown before COMMAND.
Or, forest view child tasks can yield the same effect.
So, this commit will permit the correct utf8 multibyte
display regardless of field position or string length.
And, we'll bring top into line with the ps program for
additional fields potentially subject to utf8 display.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Form its inception (back in May of 2011), escaped_copy
has always been a flawed function. It does not operate
on 'escaped' strings but instead treats all input as a
regular string incapable of containing utf8 sequences.
As such, it should only be used for strings guaranteed
to NOT contain multibyte characters (like supgid). For
all other strings, which could contain utf8 stuff, the
correct function should have been that escape_str guy.
So this commit changes nearly every escaped_copy call.
[ note: unlike the newlib guy, the master ps program ]
[ cannot properly handle utf8 multibyte sequences in ]
[ in the recently introduced 'exe' field shown below ]
Reference(s):
. Jun 2018, introduced 'exe' field
commit b556bf5ba82c7e593eb682bbf836c2bc444b2e7d
. May 2011, original escaped_copy (cmdline, cgroup)
commit 7b0fc19e9d28380dc9790615b93bc3653d6d686e
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm not sure if anyone actually uses these things, but if you
selected test fields on the command line ps would crash.
$ ps/pscommand -o _left
Signal 11 (SEGV) caught by pscommand (3.3.11.877-0488).
/home/csmall/Projects/procps/procps/ps/.libs/pscommand:ps/display.c:66: please report this bug
Segmentation fault
Anyway, it doesn't now:
$ ps/pscommand -o pid,_left,_left2,_right,_unlimited 1
PID LLLLLLLL L2L2L2L2 RRRRRRRRRRR U
1 tty7 3270/tty4 59:59 [123456789-12345] <defunct>
Use NULL in format_array to indicate that the print function shall be
used also for sorting. Change sr_nop() to NULL for all fields which
don't use pr_nop() for printing.
Before the commit (note that '--sort label' has no effect: the rows
are not sorted according to label field):
$ ps -A -o command,label --sort label | grep /lib/systemd
/lib/systemd/systemd-journa system_u:system_r:syslogd_t:s0
/lib/systemd/systemd-udevd system_u:system_r:udev_t:s0-s0:c0.c1023
/lib/systemd/systemd-networ system_u:system_r:systemd_networkd_t:s0
/lib/systemd/systemd-resolv system_u:system_r:systemd_resolved_t:s0
/lib/systemd/systemd-timesy system_u:system_r:ntpd_t:s0
/lib/systemd/systemd-logind system_u:system_r:systemd_logind_t:s0
/lib/systemd/systemd --user user_u:user_r:user_t:s0
/lib/systemd/systemd --user root:sysadm_r:sysadm_t:s0-s0:c0.c1023
grep /lib/systemd user_u:user_r:user_t:s0
After the commit, '--sort label' works and the output is sorted:
$ ps -A -o command,label --sort label | grep /lib/systemd
/lib/systemd/systemd --user root:sysadm_r:sysadm_t:s0-s0:c0.c1023
/lib/systemd/systemd-timesy system_u:system_r:ntpd_t:s0
/lib/systemd/systemd-journa system_u:system_r:syslogd_t:s0
/lib/systemd/systemd-logind system_u:system_r:systemd_logind_t:s0
/lib/systemd/systemd-networ system_u:system_r:systemd_networkd_t:s0
/lib/systemd/systemd-resolv system_u:system_r:systemd_resolved_t:s0
/lib/systemd/systemd-udevd system_u:system_r:udev_t:s0-s0:c0.c1023
/lib/systemd/systemd --user user_u:user_r:user_t:s0
grep /lib/systemd user_u:user_r:user_t:s0
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
This is part of !118 where @tt.rantala found a memory leak.
The other part of !118 may come later if the performance change
is significant.
References:
procps-ng/procps!118
This is part of !118 where @tt.rantala found a memory leak.
The other part of !118 may come later if the performance change
is significant.
References:
procps-ng/procps!118
Only need this for master, as Jim took care of exe
handling for newlib in the ad4269 change.
References:
commit b556bf5ba82c7e593eb682bbf836c2bc444b2e7d
commit ad4269f1189d5a7d68765e291bcfa981b6731c25
<utmp.h> has been deprecated since 2001 in favour of <utmpx.h>.
On glibc systems, utmp is just an alias to utmpx, so there is no
functional change using one over the other.
However, on the musl libc, a library (utmps) can be used to provide
utmpx functionality - but not utmp. This means that procps either
doesn't work properly (`w` shows nothing under musl with default no-op
implementation), or fails to build (utmps provides utmpx.h but no
utmp.h).
This commit will use utmpx.h where available, which allows `w` to work
correctly with utmps and has no change on glibc systems.
Often pidof is used in shell scripts in this form:
if pidof daemon >/dev/null; then
...
fi
The redirection to /dev/null is needed because otherwise the script
would output the found PIDs.
Let's add a -q option which, similary to grep, just sets the exit code.
Also exit on first match, as there is no reason to proceed further when
at least a process is matched.
Tested with:
$ ./pidof bash
17701 14019 5276 2967
$ echo $?
0
$ ./pidof bashx
$ echo $?
1
$ ./pidof -q bash
$ echo $?
0
$ ./pidof -q bashx
$ echo $?
1
See https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit
Support standard and high intensity colors. The default
ncurses colors ARE the high intensity colors - represented
via an 8 bit ansi escape sequence here.
See https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit
Support standard and high intensity colors. The default
ncurses colors ARE the high intensity colors - represented
via an 8 bit ansi escape sequence here.
