There is a need in some utilities to have a way of accepting both
types of decimal points "." and ",". The only way seems to be to
rebuild strtod().
This new function will accept "123.456" and "123,456" as 123.456
and considers them the same number. It means we lose thousands
separator, but this is rarely used.
test scripts are added to check the function returns the proper
values. There was simpler predecessor that got stuck on negative
0 or -0.123 which these tests flushed out.
References:
If the mapping descriptor is longer than 128 chars, the last parsed
character won't be a newline even if the current buffer contains it a
bit further than that. The current code always interprets it as a short
fgets() read instead, and thus keeps calling fgets() until it gets a
newline, dropping valid lines and failing with the following error:
pmap: ERROR: inconsistent detail field in smaps file, line:
Rss: 212 kB
If SELINUX is enabled but the machine is using another MAC system
(like apparmor), ps will fallback to just parsing
"/proc/%d/attr/current", otherwise the label/context would not
be properly displayed in that case.
References:
https://bugs.debian.org/786956
Signed-off-by: Craig Small <csmall@enc.com.au>
Commit 99fa7f removed watch crashing from having the null ANSI
sequence. However it just ignored that sequence instead of fixing it.
This change correctly checks buf (not undefined endptr) and sends
the reset attribute if found.
Closes: #12
It is documented behavior that when certain other keys
are active, sorts column highlighting will temporarily
be disabled. Among those keys is the 'L' (locate/find)
provision. The equals ('=') key can be used to restore
column highlighting by resetting other keys, except 1.
When a locate/find is active, the '=' key will have no
effect on 'x' column highlighting, which still remains
disabled. Further, when 'L' is active an 'x' keystroke
is processed changing the state of column highlighting
but without any visual clue (since it's yet disabled).
So this commit just extends the '=' key to embrace 'L'
processing resets, just like other highlight disabling
keys while avoiding 'x' state changes if approproiate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
We'll following the newlib <pids> approach to hashing:
. a 'PIDs at max depth:' portion of that UNREF_RPTHASH
enabled #define is now published only when the maximum
depth of hash table entry chains exceed depths of one.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Craig's recent commit under that newlib branch dealing
with namespace support has prompted me to review top's
handling of those fields. Currently, when such a field
is zero, top displays a dash ('-'). This will mean the
justification toggles ('j/J') will behave incorrectly.
This patch simply allows the potential zero to display
or be suppressed with the already existing '0' toggle.
Signed-off-by: Jim Warner <james.warner@comcast.net>
A patch containing the following miscellaneous tweaks:
. remove a function that handled former library errors
[ that function should have gone bye-bye with 3.3.11 ]
[ when those 'wchan' provisions were much simplified ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
ps previously followed the Unix98 standard when it comes to
user-defined output, sometimes. This meant you could have
user output format with a header that included commas and
equals signs. It was dependent on if ps thought you wanted
sysv or bsd format and THAT was dependent on things in previous
options.
It was very confusing to a user because
ps p $$ -o pid=,comm=
gave you a two-column output but
ps -p $$ -o pid=,comm=
would give you a one column output with the header ",comm="
The -p versus p means (to ps) you want sysv or bsd parsing.
Unix98 standard or not, this is plainly just silly.
The commit removes any of the quirks Unix98 has with user defined
output. If you really wanted a ps header with commas in the output,
today isn't your day.
Signed-off-by: Craig Small <csmall@enc.com.au>
configure.ac: do not check for C++ compiler
We do not have any C++ code, so there is no point in checking for C++
tools in the configure script.
Signed-off-by: John Keeping <john@keeping.me.uk>
See merge request !8
The cgroup field while shown as a vector is a concatenated
string, so alot of the complexity of sorting and displaying
has gone.
This change simplifies the cgroup sorting and adds display
and sorting for the name attribute of the cgroup, if found.
Signed-off-by: Craig Small <csmall@enc.com.au>
A rather small fix to sort by cgroup. This sorting function
could be used for other string vector entries, but I can't
see why you want to for, say, environment.
Reference:
https://bugs.debian.org/692279
Signed-off-by: Craig Small <csmall@enc.com.au>
procps v3.3.11 will bring Library API 5:0:0
The reason for the change is the removal of some calls and
the addition of others. The newlib branch should hopefully
reset some of these changes to a much slower pace.
Signed-off-by: Craig Small <csmall@enc.com.au>
.version is created in the top_srdir which when building normally
doesn't present a problem. When make distcheck is run, the source
directory is made read-only and it fails with permission denied.
The version of misc/git-version-gen is old and is missing the
instruction to add .version to EXTRA_DIST. This commit does just
that.
make distcheck now passes.
References:
https://github.com/gagern/gnulib/blob/master/build-aux/git-version-genhttps://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00000.html
Signed-off-by: Craig Small <csmall@enc.com.au>
If the -s option was the first option on the command line, free
would report seconds argument failed. This only appeared on the
Debian free, not the one in git.
Closer examination revealed that if a valid float string is
given to strtof() it doesn't set errno to 0, but just leaves it
alone. As we are explicitly testing errno for overflows, this
means the previous errno change is picked up here.
The simple answer is to set errno to 0 before calling strtof().
References:
https://bugs.debian/org/733758https://enc.com.au/2015/08/08/be-careful-with-errno/
This patch just eliminates some eol whitespace, adds a
missing eof newline and contributes yet one additional
entry to the NEWS summary regarding saved top rcfiles.
Signed-off-by: Jim Warner <james.warner@comcast.net>
ps has two columns showing the same data which is elapsed time, just
the format is changed:
etimes - elapsed time in seconds
etime - elapsed time in DD-hh:mm:ss
ps used to only sort by etime but not etimes, by making etimes
and alias of etime for sorting both flags work.
References:
https://bugs.debian.org/794619
Signed-off-by: Craig Small <csmall@enc.com.au>
While testing a newlib interface for pids acquisitions
I encountered some unexpected results if an idiot user
(me) turns off all displayable fields. So, this commit
ensures that the PID field will be shown as a minimum.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the USED column was introduced the proc_t.vm_swap
& proc_t.resident values were added together. However,
using 'resident' required an additional PROC_FILL flag
not to mention extra conversion of pages to kibibytes.
So now we'll use an already present vm_rss value which
removes any special handling for top's derived column.
And while we're at it we'll trade some more 'resident'
field uses with that more immediately usable 'vm_rss'.
Reference(s):
commit 709785e20b
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jeeze, to correct spelling on one single word (incure)
you had to go and align the entire comments paragraph?
[ well, at least there's one other minor code change ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since it's possible that euser name is not being shown
or the horizontal position had been scrolled past that
USER column, then part of those headers will be blank.
So it doesn't make sense to try and show the USER that
is associated with a process at all. Thus, this commit
simply removes the 'user' provision from both headers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Fix readlink anomalies
Noticed minor readlink issues in pidof.c and pwdx.c.
I have fixed them in two separate commits, please see the commit messages for their specific descriptions.
See merge request !5
w would error out if the window size was smaller than 71 or some
other fields through environment grew too big. The code was a little
convoluted as well. The minimum length for command was 3, which is
pretty useless.
This change does the following:
w doesn't care by default the window size
w will adjust the command length up and down, to a minimum of 7
characters.
if the fields don't fit, w will line-wrap each line.
The idea being its better the line-wrap than it is to error out.
References: https://bugs.debian.org/183394
Signed-off-by: Craig Small <csmall@enc.com.au>
If there is a PID wrap-around w will choose the wrong process.
For example:
$ ps x -o pgrp,tpgid,start,tty,cmd | grep pts/3
3834 3834 21:50:26 pts/3 ssh server
4461 4461 21:57:14 pts/2 grep pts/3
23410 3834 21:07:17 pts/3 mutt
26071 3834 Jul 13 pts/3 /bin/bash
w will show the user as:
csmall pts/3 my-laptop:S.1 13Jul15 5:54 1.36s 1.13s /bin/bash
So why?
w scans the process table and has two ways of finding the best match.
#1 match things like terminal,username and process group, find oldest
#2 match utmp pid to process tgid
The problem is that #2 trumped #1, which is fine when your login process
is numerically lower than your other processes. However in this case
26071 is larger and appears later in the readdir() than the correct
process, which is 3834.
The fix is not not overwrite best if it already exists.
Signed-off-by: Craig Small <csmall@enc.com.au>
When a user is taking advantage of the scroll features
it is likely a scrolled vertical position is well past
the first displayable task. That is especially true of
top's forest view ('V') mode where those early systemd
attached processes are generally not very interesting.
As such, should the idle mode toggle ('i') be employed
a distorted display is almost guaranteed because tasks
that have used some cpu, and thus should be displayed,
have already been skipped by virtue of their position.
So this patch temporarily nullifies vertical scrolling
during the period when idle tasks are not being shown.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The function pid_link tries to handle programs which contain very
long paths to their executables. If 1024 bytes are not enough to
contain the path, the loop wants to get more and more space until
the path can fit.
The loop's condition does not fit though.
readlink will never return a value higher than its supplied size
limit, which is "path_alloc_size - 1", therefore the loop-check of
"len == path_alloc_size" will always be false: the loop will never
be repeated.
While at it, the if-condition inside the loop's body can be omitted,
because it is always true.
malloc and realloc could return NULL when no memory is available.
The code doesn't handle errors, so use xmalloc/xrealloc instead.
While at it, sync alloclen's type with len's type, so both are ssize_t.
The previous commit got rid of some but not all the library. The
format of it was a little odd with the library being explicitly
defined instead of letting autoconf do it for you.
Fixes to option parsing in kill, skill, pkill.
Hi,
These are some fixes to how kill, skill and pkill handle parameters in the -SIGNUM form.
The handling was incorrect in kill/skill, it was actually not properly truncating argc/argv before removing the -SIGNUM argument. There were some hacks around the code to work around the bug, but using `kill -1` on its own would end up working as if `kill -1 -1` (which means `kill -HUP <all processes>`) was executed. (Yes, it was painful when I accidentally typed it... more than once.)
I also made `kill` print the usage if it only gets a signal number, but no pids (as in the `kill -1` example.)
And `pkill` had similar code but was using a buggy atoi() to try to parse the signal number, which meant that trailing garbage was accepted, so I corrected that by removing the buggy atoi() and letting the already existing code that already accepted numeric signals do its work as supposed to...
I also wanted to tackle the "pgrp" case where a negative number is passed to kill, causing it to kill a process group. The current code is buggy, for instance `kill -TERM -2345` will kill process group 2 and not process group 2345 as supposed to. It should also be possible to pass it multiple pgrps or a mix of pgrps and pids. It's hard to fix that though, considering how getopt_long() works, so I'll defer that for a second pull request.
I tested this fairly well, both manually and made sure there were no regressions in the test suite, also didn't break `make distcheck`.
Let me know if you have any questions or other remarks...
Cheers!
Filipe
See merge request !3
This commit prevents pkill from accepting something like `-1garbage` as
a SIGHUP. The previous code was using atoi() which does not check for
trailing garbage and would parse the above as 1.
Handling numeric signals in signal_option() is not really necessary,
since signal_name_to_number() will recognize numeric signals and parse
them properly using strtol() and checking for trailing garbage. It also
checks that the numeric signals are in the proper range. So all we need
to do is remove the buggy numeric signal handling here.
Tested with `pkill -1garbage sleep`, after this patch it will complain
that "1" is not a valid option, which is the expected.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This makes a command such as `kill -TERM` or `kill -9` fails and prints
usage, instead of silently succeeding.
The behavior is consistent with how `kill` behaves without an explicit
signal, or with the behavior of the `kill` builtin in a shell like bash.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
