| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is largely based upon Justin's patch, I just moved the
reset_ansi() parts out otherwise you get strange colour reset
behaviours.
Original patch message:
I used the --no-linewrap (-w) option for the first time today, watching
some wide output that didn't quite fit in my tmux pane. Quickly I
noticed a problem: while --no-linewrap did indeed eliminate the
spillover of lines too long for the terminal "window" width, it *also*
resulted in a bunch of lines from the program output being hidden
entirely.
After some fiddling around, the exact problematic behavior appears to be
as follows:
1. Lines which would have wrapped (more than $COLUMNS chars long) are
handled correctly.
2. Lines which would *not* have wrapped (shorter than $COLUMNS) are
printed; but then the next line is *not* printed! For long sequences
of non-wrap-length lines, you get an every-other-line-is-visible
sort of effect.
The logic underlying the problem seems to be this: in the run_command
loop, if the x loop goes all the way to completion (meaning we've
reached the right-side edge of the window area), there's a small block
of code for --no-linewrap whose main purpose is to call find_eol, which
eats input until it hits a newline (or EOF). Clearly this is intended to
be done for lines that are too long, so that the excess characters are
discarded and the input pointer is ready to go for the subsequent line.
However, this code isn't in any way conditional on the value of eolseen!
Short/wouldn't-wrap lines will have encountered a newline character
before exhausting the entire x loop, and therefore eolseen will be true.
Long/would-wrap lines will not have encountered a newline when the x
loop is exhausted, and so eolseen will be false.
Nevertheless, find_eol is called in *both* cases. For long lines, it
does what it's meant to do. For short lines, *the newline has already
been encountered and dealt with*, and so the actual effect of find_eol
is to eat the entirety of the next line, all the way through to its
newline, such that it isn't printed at all.
References:
procps-ng/procps!157
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
|
|
|
| |
If you have the watched program doing some other thing every time its
run and you resize the window, you might get unexpected results. The
-r option lets you run only when the interval has expired.
References:
procps-ng/procps!125
procps-ng/procps#190
|
|
|
|
|
|
|
|
| |
Based upon merge request 104, closes #174
References:
procps-ng/procps!104
procps-ng/procps#174
|
|
|
|
|
| |
References:
procps-ng/procps!156
|
|
|
|
|
|
| |
References:
commit 5baf1e6226f9aa051b5570b655ed49b73ae10061
procps-ng/procps!159
|
|
|
|
|
|
| |
References:
commit 866abacf8805a74fb7c59cae1f64963e0a540b14
procps-ng/procps!165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the p/e-cores support (via the '5' key) was added
in the patch referenced below, I intentionally omitted
that key from the top primary help screen. This seemed
appropriate since it only applied to select Intel cpus
and, besides, that screen was getting kind of crowded.
[ it remains an objective to fit on a 80x24 terminal ]
Upon reflection, I found a way to squeeze it into that
help screen and have decided to included it. Hopefully
its presence will encourage use of top's new provision
on any Intel platforms that distinguish between cores.
Reference(s):
Sep, 2022 - exploit p/e-cores provision
commit 00f5c74b1bc583d37315fa094c6f50cef7961c0c
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
| |
vmstat <n> would update most fields, but the memory statistics
were only fetched the first time.
References:
https://bugs.debian.org/1027963
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
There was a bug fix in the library but no functions add/moved/changed
Revision incremented.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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 b89e3230b2baa5b82a2961b240731db95a887f26
|
| |
|
|
|
|
|
| |
References:
procps-ng/procps!163
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
| |
Added NEWS item
Update pgrep.1 date
References:
commit 4b44ab98c144dae099442e30a62966a7689818c6
|
|
|
|
|
|
|
|
|
|
| |
The newlib library used to be called libproc-2 but the new
name is preferred.
References:
https://www.freelists.org/post/procps/Next-for-newlib,3
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If procps is built on a Linux 5.3+ system then pidwait
is built with pidfd_open(). If that program is run on
a system < 5.3 then it gives an odd generic error.
If we get a ENOSYS from one pid, we will get it for all
the others so its better to explain what happens and terminate.
The man page is updated to note this issue.
This came up due to killall in psmisc using pidfd_send_signal
References:
https://bugs.debian.org/1015228
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
| |
Added note to NEWS in the lbirary section
Updated free.1 as it specifies the calculation
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
| |
[ along the way, we'll fix-up the section 4 commands ]
[ summary which has gotten a little outdated lately. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
| |
References:
commit 3ac20bf5366b5784d8ee4b1f927e96f4dd164f28
|
|
|
|
|
|
|
| |
[ along the way we will restore '^R' to keys summary ]
[ plus correct a leftover reference to 'Ctrl-V' too. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
| |
pmap uses freopen to read /proc/self/maps. There doesn't
seem to be a good reason to do this and if pmap has its
stdin previously closed then it fails.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of the issue referenced below, we'll trade
our homegrown offset generator for an 'offsetof' macro
found in the stddef.h header file. This pleases clang.
[ and thanks to Daniel Kolesa for the report and fix ]
Reference(s):
. bug report & recommended solution
https://gitlab.com/procps-ng/procps/-/issues/235
. clang error message
proc/readproc.c:673:9: error: initializer element is not a compile-time constant
mkENT(Rss),
^~~~~~~~~~
proc/readproc.c:661:34: note: expanded from macro 'mkENT'
#define mkENT(F) { #F ":", -1, (int)((void*)&q->smap_ ## F - (void*)&q->fZERO) }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the globbing update was put into sysctl, you could no longer
simply use the keys because one key could potentially be
multiple paths once the glob expansion occured. Using the path
instead gave a unique output.
Except certain programs, such as salt, expected the output to use
the dotted path "kernel.hostname" and not "kernel/hostname".
We can no longer use the original key, so now for each path:
Copy the path
strip off /proc/
convert all / to .
The sysctl testsuite was also updated to check for a few different
types of conversion failures.
References:
commit 6389deca5bf667f5fab5912acde78ba8e0febbc7
https://www.freelists.org/post/procps/some-procpsn4400-fixes,4
https://repo.saltproject.io/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
| |
Reference:
procps-ng/procps!151
|
| |
|
|
|
|
|
|
|
|
| |
[ 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>
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit used the value from mbstowcs() to work out
the spacing required, as printf() got it completely wrong.
However, for alignment of text you don't use the string length
but the string width.
As the referenced website says:
Use wcslen when allocating memory for wide characters, and use wcswidth to
align text.
Which is what free does now. Chinese is still off by one but I cannot
see why this is so. It's close enough for now. If someone can work
it out, I'd love to know what the fix is.
As a side effect, #213 is fixed because we are putting the correct
number of spaces in.
French is still an issue (see #24 ) but this is because the string is
too long!
References:
procps-ng/procps#24
procps-ng/procps#213
procps-ng/procps#229
commit 9f4db0fb5606e4872829bd44b29443d5707b1505
https://www.linux.com/news/programming-wide-characters/
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
free has for many years had a problem with translated header columns
or the first column. This is because printf("-9s", str) doesn't use
the wide length of the string but the char length meaning they are
mis-aligned.
Using the mbstowcs() function to get the wide length and then
a precision parameter to append the right number of spaces after the
number means we get what we need.
References:
procps-ng/procps#229
procps-ng/procps#204
procps-ng/procps#206
https://bugs.debian.org/1001689
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
| |
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can match or filter on cgroup paths. Currently the match is only
done for version 2 cgroups because these are way simpler as they have
a unified name and always start with "0::".
cgroup v1 can have:
named groups "1:name=myspecialname:"
controllers "9:blkio:"
multiple controllers! "4:cpu,cpuacct:"
So they are very much more complicated from a options parsing and
cgroup matching point of view.
In addition, both my Debian bookworm and bullseye systems use
v2 cgroups.
$ ./pgrep --cgroup /system.slice/cron.service
760
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
| |
References:
commit 91e58792282d676fbcb3781d2ed48d6b082c6c56
Issues #133 #223
merge !140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR revisits a partial fix from 2018. The problem stems from incorrect
handling of unsigned 32-bit uid_ts and gid_ts as signed when values are
large - i.e. when the high bit is set. In that case, pgrep and pkill fail to
identify processes by uid. (They succeed when finding the same processes by
username.) The primary fix for this is to impliment the "FIXME" comment in
proc/readproc.h, the implementation of which allows the removal of the (int)
casts from the partial fix from 2018.
The other fixed code in this MR consists of tests in strict_atol() that
detects and errors out on overflows.
References:
Merge !146
|
|
|
|
|
|
|
|
|
|
|
| |
uptime -p would show empty output after 52 weeks of uptime. This commit
is largely the work of Ed but reformatted for newlib branch.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
References:
procps-ng/procps!141
procps-ng/procps#217
|
| |
|
|
|
|
|
| |
References:
commit b6ccf865f83f98478a814c1d79d17a0b5212cc6e
|
|
|
|
|
| |
References:
procps-ng/procps#77
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Real usecase:
'sysctl -w user.max_uts_namespaces=2147483648; echo $?'
returns 0 even though it failed with EINVAL
The close_stream() realised there was an issue and printed an
error but didn't change the return value.
Slightly modified merge request.
References:
procps-ng/procps!76
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
| |
References:
procps-ng/procps!91
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
systemd-sysctl handles glob patterns along with overrides and
exceptions. Now the procps sysctl does it too.
The return value for sysctl is consistently either 0 or 1.
Added tests to check sysctl functions.
References:
procps-ng/procps#191
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|