program fuzzy search

[rongyi]

this is an enhancement suggestion, the program search is a fully match, can me make it fuzzy? I already hack this for my personal use, but dont kown upstream need this change, so I keep it here for maintainer to decide.

https://github.com/rongyi/somo/blob/a61c5ecb638131f20bf90100cf1c65e39c01c154/src/connections.rs#L134

also program can include argument, e.g. when multiple java process running in one server, the java command can not decide which process, so for me the process argument included is very easy to locate the process I want.

https://github.com/rongyi/somo/blob/a61c5ecb638131f20bf90100cf1c65e39c01c154/src/connections.rs#L108

[theopfr]

Hey, I will check this out as soon as I get to it (I don't quite understand it yet haha)

[gerelef]

would the following suffice for a fuzzy search w/ a live window that refreshes its contents while writing? fzf required, naturally

change $FZF_DEFAULT_COMMAND as required

FZF_DEFAULT_COMMAND="./target/debug/somo --compact" fzf \
--ansi \
--no-sort \
--reverse \
--bind 'change:reload(eval "$FZF_DEFAULT_COMMAND")'

[theopfr]

Okay so here is my understanding of this issue:

1. The main goal is to have more information about a process, for example as seen in this screenshot where two flask servers are running but we can see the full information about them:
   

Compared to currently, where we would just see two processes with the name "flask".

2. Then for the --program flag we would want a fuzzy match because if we have many similar programs we would like to get them all.

About 1:
I see how this can be very useful... I'm not sure how good this is from a UX perspective because these entries can get very long, for example:

But we could add a flag, maybe called --extended/-e to get more extensive information.

About 2:
Fuzzy matching would make sense I think. At least for program, for numerics it would be problematic. So yea I'm open to keep fuzzy matching for program names.

[theopfr]

would the following suffice for a fuzzy search w/ a live window that refreshes its contents while writing? fzf required, naturally

change $FZF_DEFAULT_COMMAND as required

FZF_DEFAULT_COMMAND="./target/debug/somo --compact" fzf \
--ansi \
--no-sort \
--reverse \
--bind 'change:reload(eval "$FZF_DEFAULT_COMMAND")'

This is quite cool. Fuzzy matching for interactively searching through the somo table defintely makes sense (compared to fuzzy matching for filtering, where IMO it only makes sense for program names).

[gerelef]

Okay so here is my understanding of this issue:

1. The main goal is to have more information about a process, for example as seen in this screenshot where two flask servers are running but we can see the full information about them:
   

Compared to currently, where we would just see two processes with the name "flask".

2. Then for the --program flag we would want a fuzzy match because if we have many similar programs we would like to get them all.

About 1: I see how this can be very useful... I'm not sure how good this is from a UX perspective because these entries can get very long, for example:

But we could add a flag, maybe called --extended/-e to get more extensive information.

About 2: Fuzzy matching would make sense I think. At least for program, for numerics it would be problematic. So yea I'm open to keep fuzzy matching for program names.

I suppose we could add an extra column for a program's cmdline... but this feels slightly out of scope, does it not? matching PIDs to a cmdline with other utils in order to see the cmdline invocation, even though it is not trivial, shouldn't be too much. I guess it all depends on the use case...

I do think fuzzy searching for the program names by themselves makes sense, but that opens a whole can of worms where we step into awk/regex land, trying to select columns that could start, end, contain or fuzzy match a specific key... feature creep is a real issue!

we could just *match* a given regex, instead in the first place, no? but that is kind of overkill right now as well, given that there is no pid :P also regex matching cmdline values sounds bothersome so I won't assume anything about OP's usecase.

I wonder, if we could ship complementary utilities alongside somo instead, perhaps.

If @rongyi could elaborate on how he uses the software with the extra functionality he patched, that would clear things up regarding ux & feature changes, I gather.

[rongyi]

@theopfr exactly as you said, two flash will only show python, which I need to use ps aux|grep python to match which process. the process is mainly answer this question: I want to know which process is listen to tcp port 8080, nomally I need 2 steps

1. netsate -nltp |grep 8080 # to get pid
2. ps aux|grep $pid # to get process

but with hacked somo, only one command can fufill my requirement. that's it.

[gerelef]

does exposing .cmdline() in --format sound like a good compromise for advanced functionality? for example, you would be able to write:

./target/debug/somo --format "{{local_port}},{{remote_address}},{{pid}},{{state}},{{program}},{{cmdline}}" | awk -F ',' '/8080/{ print $0 }'

and the output would be very scriptable, if u want to automatically kill processes if it matches some rule you set or something :)

I suppose we could even export all the environment variables of a process this way as well if we wished, since we're going for advanced functionality...

edit: @theopfr I wonder if it makes sense to add a pretty-format for this capability as well, too; as in, a nice table-view of a custom format.

edit: surprisingly, you would be able to combine the output above with fzf as I said previously, so you could have a fuzzy search for all 8080 processes as well.

[theopfr]

does exposing .cmdline() in --format sound like a good compromise for advanced functionality?

Hmm seems then a bit like a detour to me that you have to use --format just to get a more extensive list of your processes (if I'm currectly undertanding). I would be more in favour to add a flag that gives the entire cmdline besides of the program name. If we the new flag would have a program column and a cmdline colum, then you can filter by the program name and get all your, e.g, Java processes and then check the different cmdlines to find what you are interested it. And then I would keep the fuzzy matching out for now. Does this sound good to you guys? (Sorry, just saw that this is basically what @gerelef wrote in the comment above)

I wonder if it makes sense to add a pretty-format for this capability as well, too; as in, a nice table-view of a custom format.

Not sure how this would look like though because the thing about the --format output is that it can have any arbitrary form, so I don't know how we could make sure that it fits into table view, eg. what if I do this (for whatever reason): somo --format "The program {{program}} runs on port {{port}}"?

@gerelef

[gerelef]

Hmm seems then a bit like a detour to me that you have to use --format just to get a more extensive list of your processes (if I'm currectly undertanding).

I guess it is a trade-off between functionality & ease of use -- too much information is just as bad as too little I guess. It really depends on the use-case here and your vision for the utility itself.

Not sure how this would look like though because the thing about the --format output is that it can have any arbitrary form, so I don't know how we could make sure that it fits into table view, eg. what if I do this (for whatever reason): somo --format "The program {{program}} runs on port {{port}}"?

you are right, I was thinking from a scripting perspective with well-defined columns where a user has only changed the column separator & their order...