Show process commands in ps::ps()?

[wlandau]

Would it be feasible to show the command of each process in the output of ps::ps()? I think this would make processes easier to find.

[gaborcsardi]

It is in the name column, e.g.

❯ ps::ps()[1:3,]
      pid ppid            name    username  status        user      system
387 43046    1 mdworker_shared  _spotlight running          NA          NA
384 42813    1 mdworker_shared gaborcsardi running 0.001497810 0.000657654
383 42812    1 mdworker_shared gaborcsardi running 0.001383352 0.000671527
         rss          vms             created    ps_handle
387       NA           NA 2023-03-15 20:13:47 <ps::ps_....
384 13746176 418009563136 2023-03-15 20:13:36 <ps::ps_....
383 20447232 418009563136 2023-03-15 20:13:36 <ps::ps_....

[wlandau]

Thanks for confirming, I would not have known. Would it be possible to have more descriptive names? For example, when I call mirai::daemons(n = 1L, url = "ws://127.0.0.1:5000"), it launches a "dispatcher" background process that recently taken some work to diagnose and mitigate. in ps::ps(), the name is simply "R". But in htop, the command is much more descriptive and allows me to easily distinguish that process from other R processes.

Would it be possible to access these more descriptive commands somehow in ps()?

[gaborcsardi]

Those are not names but the command line arguments, and you can use ps::ps_cmdline() to access then. E.g. you can select the processes named R and then call ps::ps_cmdline() on their ps_handle column.

[wlandau]

I see, ps_cmdline() helps. However, it can be cumbersome to search this way in the interactive console while transient R processes are coming and going. Would you be open to including these commands in the table directly, or do you prefer to keep the table light? Alternatively I could see the value in a simple interface that gives some control of the column selection to the user. I have found tidyselect to be convenient for e.g. the names and fields arguments of targets::tar_meta(), which would otherwise return a large and cumbersome data frame, but maybe tidyselect itself is too dependency-heavy for ps.

[gaborcsardi]

However, it can be cumbersome to search this way in the interactive console while transient R processes are coming and going.

Why is that a problem and how would the change help?

Command line arguments can be very long (thousands of characters), so the output would be very messy if we printed them, even if we truncate them.

It is pretty easy to query them if you need them:

p <- ps::ps()
cmd <- lapply(p$ps_handle, function(x) {
  tryCatch(ps::ps_cmdline(x), error = function(e) NULL)
})

I don't mind an API that can you can use to select columns (not with tidyselect, though), but it is unlikely that I'll have time to add that any time soon.

[wlandau]

It is pretty easy to query them if you need them:

Fair enough, those 4 lines are pretty simple. I just generally expect this sort of task to barely require thought at the interface level.

I don't mind an API that can you can use to select columns (not with tidyselect, though), but it is unlikely that I'll have time to add that any time soon.

No worries, I totally understand.

[thomascwells]

I picked this up to look at as part of tidy-dev-day. Thinking through the problem a little, I didn't come up with a good solution to adding the API. I wanted to jot down some of my thinking here and get feedback.

One option might be adding a verbose argument which could include some additional columns, like the command line arguments and any future additional that might be added.

Another option could be a cols argument which would default to a subset of cols, but could be expanded to include all available cols or a smaller set of columns. I'm not sure of the real value-add of this approach though, especially given that the three-liner lapply() offered above is pretty simple and aligns with the spirit of the Recipes section of the README.

Thoughts? Maybe @wlandau 's use-case has evolved in the past year as well?

[gaborcsardi]

I think we can add a columns (or similar) arguments.