htop-dev / htop Goto Github PK

Although the blank margin around the header can be removed by a configuration setting already I think it's a waste of valueable screen estate to have it enabled by default, as it wastes two rows of your terminal height placing no information. As the density of information of most other parts of htop is quite high this seems a bit counter-intuitive to have this blank area on by default.

I installed it, but I cannot find the file, oddly, where is the executable placed?

First of all, I'm really glad to see development happening on this project again!

With v3.0.0 attempting to add the battery meter crashes htop with the following error:

htop: No such file or directory

I'm running Arch Linux with the 5.8.1 kernel.

One long-standing bug I'd love to see resolved is the problem with sorting by the OOM column. Currently the order seems to jump around at random.

Hi!

See: https://github.com/shlomif/plea-to-not-use-github-tags-as-releases/blob/master/article.md . One can attach them to the GitHub's tag. Thanks for maintaining htop!

The current README has a link to INSTALL and that file is missing

There are several places where the source does an explicit comparison of floating point numbers with constants (in particular the battery state feature). As comparing floating point numbers with ==/!= is unsafe, and the compared to values are for error cases (i.e. value unavailable) the better solution would be using NAN and check for the error case with isnan() instead of abusing those magic values.

Compile with gcc -Wfloat-equal to see those issues in the source.

If you like I can try to whip up some patch, though for consistency the semantic of some APIs might need slight changes (N/A and errors as NAN instead of -1 for e.g. the battery level).

Ref: Issue hishamhm/htop#801 and pull request hishamhm/htop#809

Summary:
I) On Linux a process is able to modify its own command name (/proc/pid/comm) say using prctl, and its own command line (/proc/pid/cmdline) say by writing into its arguments vector. But /proc/pid/exe is set by the kernel and provides the definitive location of the executable image. While htop currently displays cmdline, for the above reason it is desirable to display the executable image path and command name, along with cmdline, merging them where possible.

II) While htop currently sorts/filters the Command based always on cmdline, irrespective of whether it is full path or basename that is displayed, it is desirable to sort/filter based on what is displayed.

Please add an option to hide zeros from the output.

This way it's a lot easier to parse especially since many columns are zero most of the time (MEM and CPU).

Thank you!

Repost from: hishamhm/htop#944

Repost of hishamhm/htop#837

Short description:
Allow for marking new/old entries in the process view similar to what SysInternals Process Explorer does.

Screenshot:

System Xubuntu 20.04.

.configure && make brings "configure: error: missing libraries: libncurses"

I do an additional installation (to libncurses6 and libncurses-dev) of:

• libncurses5-dev (transitional package for libncurses-dev)
• libncurses5 (shared libraries for terminal handling (legacy version))

After the program libraries have been set up, the installation runs.

I would like to get to the following view as soon as possible. Currently that means f6 down f6 down ..

Solutions that I would be happy with:

• A shortcut to toggle all children of selected, for instance shift f6.
• Tree view have collapsed all by default (recursive). Expand will just expand the selected element, not recursive.

Relevant issues at original htop-repo:

• hishamhm/htop#24 (latest responses argue that it should be collapsed by default)
• hishamhm/htop#510 (pull request for collapse all)

Repost from: hishamhm/htop#836

Short Description:
Allow the user to select some processes/threads of interest and after activating the filter view only show those or any children.

Detailed explanation in hishamhm/htop#836 (comment)

Software built with autotools is typically released with tarballs containing the already generated configure script and friends. This was also true of htop prior to this fork. Will this practice be continued here?

When searching for a process with vim keys enabled, you cannot use HJKL keys. It instead closes the search box and starts navigating instead.

The docs currently say that htop depends on ncurses, but they leave open the question
of how precisely to install ncurses on the many systems that package it in so many ways.

In the interests of reducing the frequency of ncurses-related issues - like #85 #36 #82 -
this issue will be resolved with a PR for a new file in the docs README-ncurses.md with
install instructions.

Ideally, this will be fodder for some kind of CI infrastructure that automatically tests those
directives when it builds and tests across a variety of operating systems.

The old repository by hishamhm had a pull request about graph meter coloring & dynamic scaling.
This was developed by @Explorer09, but was never merged upstream. Any chance to rework and merge it now?

Currently the autoconf script has to go through extra hoops to figure out where curses is and how to include it. This leads to a pile of ifdef soup in the code and is making me pull my hair out in #80 trying to figure out how to do this on all supported systems. So I suggest we just #include <curses.h> by default. Of all the systems I tried, curses.h is either a link/include to some ncurses header or is it's own implementation that provides wide-char support. If downstream really needs to link against their special snowflake curses library, then they should insert the proper (C|CPP|LD)FLAGS themselves. In other words, assume a sane default and make it a compile-time error so it blows up in their faces.

its great and all this is still maintained, but I dont enjoy things becoming less readable. you could argue here "use a better font" but htop is used in a lot of minimal installs that might be lacking all and any fancy glyphs, which is why the old method of checkmarks is used in nearly every cli program

The generated header files always bugged me in this project. Are others also have the opinion, that this should be changed once and for all.

For example, most non-linux headers are out of date, after extern was added to function declarations. (Why an extern was added to function declarations is a mystery in its own to me though).

After this commit - d0f31ed сheckboxes are poorly displayed in the program settings.

or share precompiled statically binary on github and on your site, as many program developers do nowadays, it would be the best and the easiest solution.

I think that the old style occupies fewer columns, and is consistant with the style of other numbers.
(If you have no permission, just show "???")
(Old style in 1.0.3 and new style)

htop-master/solaris/SolarisProcess.c: line 154
` case ZONE:{
xSnprintf(buffer, n, "%-*s ", ZONENAME_MAX/4, sp->zname); break;

  if (buffer[ZONENAME_MAX/4] != '\0') {    // <-- unreachable
     buffer[ZONENAME_MAX/4] = ' ';
     buffer[(ZONENAME_MAX/4)+1] = '\0';
  }
  break;

}`

See hishamhm/htop#901.

On Ubuntu 20.04, after installation (from 3.0.0 tarball or github master) I get the error message:

htop: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory

Would you like to add more error handling for return values from functions like the following?

• fclose ⇒ Settings_write
• fputs ⇒ printVersionFlag

Hi

It is possible to add the temperature patch, so the AUR package htop-temperature won't be needed anymore?

The patch itself is available here.

Thank you very much!

I understand that hisham has not been as active, probably due to lack of time and commitments
in reallife. I think it would still be useful to show the key goals for htop-dev, and, even more
importantly, the status of the old htop, e. g. whether it will stay or not.

(I was instantly able to compile htop-dev from source, and it works, whereas the old htop has
problems finding my compiled ncurses variant, so i assume htop-dev probably also changed
build/compile stuff, updating ncurses related aspects - but I am just guessing.)

It would be good to show total values for selected processes for each column (mem/io/time/cpu)

The arrow keys probably should always work regardless the vim mode is on or off.

Not a bug, just a heads up because this wildly messes with the VIRT column. (Everything is red, and the number of significant digits goes waaay down.) On my computer this region is reliably located here:

GPU Carveout (reserved       1000000000-7000000000       [384.0G     0K     0K     0K] ---/--- SM=NUL          ... address space (unallocated)

Maybe this might be worth adding special accounting for?

Can anyone tag and migrate all previous releases from https://github.com/hishamhm/htop/releases ?

The readme indicates that the configure script should be packaged with release tarballs. This doesn't seem to be the case for htop-3.0.0.tar.gz, meaning that autoconf is a requirement for building htop.

On a side note, I'm glad to see some activity again :)

If I set the PSI or System load meters' style to "bar", they show the 3 values stacked together, which is ridiculous.
Also, all 3 PSI stats are labelled "Som" or "Ful".

My recommendations:

For Load average, show a green bar from 0 to 1, a yellow bar over it from 1 to physical CPU count, and finally a red bar over it when the load is between 1x to 2x of physical CPU count.
Mockup:

For PSI labelling:
S-C (Some CPU), S-M (Some Memory), S-I (Some I/O), F-M (Full Memory) and F-I (Full I/O).

After upgrade to 3.0.0, htop can't open in my laptop and just print htop: No such file or directory.
I use bisect to find out 1886117 cause this issue.
This commit is ok but const char filePath[50]; is too small to store /sys/class/power_supply/ucsi-source-psy-USBC000:001/type which is 57 bytes without \0.
Changing the buffer size to 70 can fix this issue.

Congrats on version 3 and adding new features.

I was wondering if there were plans to bring this to package managers like the original htop did or would it just be provided through those channels.

Additionally, is providing this tool as a snap or flatpak a possibility?

I know htop is a system monitor, and not meant to read sensors, but it is useful to have all the temperature metrics right next to your core clocks and other metrics, especially for overclocking or trying not to burn your cpu

Any column which contains values in both bytes and megabytes has inconsistent highlighting applied to it. I'm actually not sure what the purpose of the column being highlighted is in the first place. Any idea what that is supposed to indicate?

When reconfiguring the list of displayed columns in the process view it's always somewhat cumbersome to add one column, exit the editor view, look if the display looks/feels like intended, reenter the editor and possibly do the next change.

To improve the UI in this respect it might be a nice idea to include a sample of 2-3 processes/threads at the bottom of the display as a preview of the selected columns and additionally (as space permits) sample values for the various columns you can select for inclusion.

Also for some columns (e.g. cgroup names) it might be good to introduce a somewhat "shortened" version (/sys/cgroup/lxc/container1 -> container1) to safe space.

Hi there,

AIX support was started in the old repository
hishamhm/htop#832

Is this still possible to port over and finish?

Thanks.

can we have a screenshot in the readme?

With htop 3.0.0 once battery meter is added or if old htoprc (from 2.2.0) is used (where it was already added and working), htop immediately exits with the following message:

htop: No such file or directory

strace shows this:

openat(AT_FDCWD, "/proc/acpi/battery/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/acpi/ac_adapter", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/sys/class/power_supply", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents64(4, 0x55e6aa023d40 /* 8 entries */, 32768) = 272
openat(AT_FDCWD, "/sys/class/power_supply/./type", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/sys/class/power_supply/../type", O_RDONLY) = -1 ENOENT (No such file or directory)
write(1, "\33[?12l\33[?25h", 12)        = 12
write(1, "\33[?1006;1000l", 13)         = 13
write(1, "\33[38;1H\33[?1049l\33[23;0;0t\r\33[?1l\33>", 32) = 32
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
write(2, "htop: No such file or directory\n", 32) = 32
exit_group(1)                           = ?

This happens on Lenovo T490s.

When I installed master on my computer, it failed with the error message

htop: error while loading shared libraries: libtinfow.so.6: cannot open shared object file: No such file or directory

Hello,

I read that this is sort of the "htop 3" branch. In the old release schemes we had something
like this:

https://hisham.hm/htop/releases/2.2.0/htop-2.2.0.tar.gz

Not sure if we had this for htop on github.

Would it be possible to also release a htop-3.0.0.tar.gz or .tar.xz?

Right now we don't have that at https://github.com/htop-dev/htop/releases. It would
simplify a few downstream scripts that I use (and perhaps others too).

Error
configure: error: You may want to use --disable-unicode or install libncursesw.

I have some ncurses libraries already installed:

I already have ncdu - a ncurses based du viewer on my system, so it seems strange that I am getting this error.

Ubuntu based, Linux Mint 19.3

Cool to see this project continue in some official form!

Previously, I had been using a patch to get vim bindings to work. There's one binding I really miss however (perhaps there are more I haven't discovered yet), namely one to move to the top and bottom of the process list with g and G respectively. Should be fairly easy to add (see also the patch I linked), though I'm not much of a programmer myself anymore.

Please add the ability to display process capabilities.
To view process capabilities, I usually use the command:

sudo cat /proc/2020/status | grep Cap

CapInh: 0000000001000400
CapPrm: 0000000001000400
CapEff: 0000000001000400
CapBnd: 0000000001000400
CapAmb: 0000000001000400

or:

sudo getpcaps 2020

Capabilities for `2020': = cap_net_bind_service,cap_sys_resource+eip

Description of problem:
CTID doesn't show openvz container id

Version-Release number of selected component (if applicable):
htop-2.2.0-3.el7.x86_64

How reproducible:
always

Steps to Reproduce:

1. running on vzkernel-3.10.0-862.20.2.vz7.73.29.x86_64
2. start container(s)
3. launch htop (on HN)
4. show CTID column

Actual results:
CTID 0 for all processes

Expected results:
correct container IDs

for further details see comments in: https://bugzilla.redhat.com/show_bug.cgi?id=1694265