Add 'press D to attach debugger' feature

[mic-e]

No description provided.

[rien333]

Note that g conflicts with a binding that is commonly used in builds that support a vim mode (see #25 — if this ever becomes implemented, at least).

[mic-e]

Unfortunate. Which keys are free in vim mode?
Would features like 'attach strace' work the same way in vim mode, i.e. by pressing 's'?

[rien333]

Unfortunate. Which keys are free in vim mode?

Good question. Most key combos with modifiers other than shift are available. Currently, htop includes only a small number of vim keys (see 12805f6 + maybe / for searching).

At this point, g is completely free in htop 3.0, even in vim mode. However, htop 2.X with vim patches applied often did include g and G bindings, so that might change. Perhaphs you could use d (as in, "d" for debugging) instead of g for launching gdb in vim mode? (or just use d accross the board)?

[mic-e]

Sounds good :)

I have switched the key to d and also made the debugger configurable through htoprc so if you want to use lldb you now can

[cgzones]

Maybe htop should check the ownership of the configuration file it's about to read, so that no un-privileged user can by accident modify a privileged configuration file and inject commands.

(Another unrelated personal thought is to set the value to NULL, i.e. disable the feature by default, so if someone fat-fingers the key d nothing happens.)

[mic-e]

Should I add an ownership check in general and refuse to read the file if (g+w || o+w) is set, or just for this specific setting?

[mic-e]

Re your unrelated personal thought: I don't think that's necessary; if people don't have gdb installed, nothing will happen when they fat-finger d. If they do have gdb installed, well, it's likely that they know what they're doing, and if they pressed the key by accident they know how to leave gdb.

[mic-e]

Re again: I've changed it to D which should be less likely to be hit by accident.

[mic-e]

Regarding your request to check the ownership:

I think that this could be accomplished using the following code to Settings_read():

   bool trusted = true;
   struct stat64 file_stat;
   fstat64(fileno(fd), &file_stat);
   if (file_stat.st_uid != getuid32()) {
      printf("warning: htop settings file is not owned by uid %d\n", getuid32());
      trusted = false;
   } else if (file_stat.st_gid != getgid32()) {
      printf("warning: htop settings file is not owned by gid %d\n", getgid32());
      trusted = false;
   } else if (file_stat.st_mode & 0002) {
      printf("warning: htop settings file is writable by others\n");
      trusted = false;
   }

And then ignoring certain values if trusted == false.

However, having implemented this and thought about it for a bit, I now strongly oppose the idea because:

• It can be easily circumvented by an attacker who has write permissions to any folder in the hierarchy
• It prevents the config from working when I launch htop with sudo
• If somebody manages to manipulate the htop config in my home folder, they could just as well inject stuff into my .bashrc. Other tools like bash don't check their config files for permissions either.
• ssh used to check its config files for permission bits but this was removed because it caused too much pain and actually decreased security by e.g. preventing users from putting their secret keys onto flash drives
• I think ACLs would be ignored

(unless I misunderstood your request?)

[BenBE]

In VIM mode d would be a natural choice to kill ('drop') a process, as k is blocked by the navigation keys.

What about b for 'bug search' for gdb?

[mic-e]

b seems a bit far-fetched... maybe shift+D, which would also defuse the fat-fingering issue?

[rien333]

In VIM mode d would be a natural choice to kill ('drop') a process, as k is blocked by the navigation keys.

I haven't seen any vim patches that use 'd' for this I think. Rather, most (including this project prior to the moment vim-mode got temporarily dropped) seem to use K (i.e. shift+k). Though shift+d may work nicely as well.

The best solution would of course be if htop would allow users to bind various action-primitives to keys in some configuration file (like other good TUI/GUI unixy programs like cmus, mpv, zathura, qutebrowser, emacs), instead of being force-fed some control scheme.

[mic-e]

re-based to current master

[fasterit]

We discussed this proposal in the core team yesterday. We do not want to add more single purpose tools with hotkeys. Needing to attach a debugger is such a seldom need over the whole user base that it does not make sense to add it specifically.

That said, what we would like to see implemented is the functionality to start a $XDG_CONFIG_HOME/htop/run_script on a key press (possibly r):
run_script would be called with "PID" "USER" "COMMAND" on the currently highlighted line.
Bonus points for providing a sequence of "PID" "USER" "COMMAND" on stdin if multiple processes are tagged (=marked).
Bonus points for making the script location configurable in /etc/htoprc so that system-wide defaults could be set (having a $XDG_CONFIG_HOME/htop/run_script present would override the global setting still). This would (automatically) also allow to override the script location for a user in their local htoprc (same config reader).

If run_script outputs on stdout and/or stderr this would go into the InfoScreen pager. Otherwise htop would just return to normal operations once the exec* returns. See OpenFilesScreen.c or TraceScreen.cfor inspiration.

Attaching a gdb could be a htop-supplied example of how to use such a script.

Would you be interested in implementing such a function?

[TheJJ]

I've whished for such a feature for a really long time, since launching gdb is just the next step to strace and lsof.
But I understand your concern regarding single-purpose keys.

How about we make all keys configurable, so I can define my gdb launcher? That means not a single possible run_script, rather, configurable keys for everything and arbitrary commands and key combinations, ...
The defaults obviously remain like people are used to.

And if you do insist on a single key, please allow the tool to be interactive, i.e. not always wrap it into a pager. that way one could at least do a sub-menu in this script where the actual action is then selected (e.g. gdb, lldb, r2, ...).

[BenBE]

The concern in the team was less with having this script part limited to just one™ action only, but that implementing just starting one program, hard-coded into htop would open up a rabbit hole we don't want to start going down.

What might work just fine should be to allow for an arbitrary number of commands to be configured, all with their run_script obeying the format specified by htop ("an API"). Upon pressing the "run tool" key you could then get a menu to select the one™ you want to start before passes on control to that script and displays it's output.

Passing thru all keys might be somewhat tricky, but could be managed by some "interactive command mode" where htop effectively relinquishes control of the terminal until that executed command terminates (e.g. for gdb). For non-interactive commands this might continue to behave just like strace is currently implemented.

Regarding keybindings: That's a kinda complicated one, as there historically have been various attempts to implement something like a VIM mode, which regularly collided with existing key bindings or where you just couldn't get the required keyboard handling work reliably. Also having the keymap fixed for now, until a good solution to implement VIM mode and other key-binding related issues, might simplify going forward with having a good baseline for implementing the keymap modification features later. Thus for now I'd suggest keeping with one key for external commands (what about r for run?) and displaying a menu to select the actual command from there (or run directly, if just one such command is configured).

[TheJJ]

Yea that sounds good for now, having a run-tool key like r and defining a call-api (e.g. via env-vars?) so i could have a python-dispatcher that then invokes whatever tool necessary.

I think as the long-term-goal htop would benefit a lot if one could freely assign keys to actions, so you could have a htop, vim, emacs, whatever mode by rearranging the bindings in the config file.

[BenBE]

Yea that sounds good for now, having a run-tool key like r and defining a call-api (e.g. via env-vars?) so i could have a python-dispatcher that then invokes whatever tool necessary.

Do you mind extending this PR in that direction? / Open a new one to superseed this one?

I think as the long-term-goal htop would benefit a lot if one could freely assign keys to actions, so you could have a htop, vim, emacs, whatever mode by rearranging the bindings in the config file.

Fully customizable key bindings for htop is probably a long-term goal and should be handled independent of this PR. But given there have been inquiries about this repeatedly in the past, there seems to be some interest in it.

[fasterit]

Closed in favor of the more general approach to be implemented cf. #506