[WIP] Flexible search plugin (via Unix pipes) #172
+764
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE: This is a WORK IN PROGRESS, and is not yet ready to be merged. Looking for early feedback, as well as rust tips and improvements to memory management and/or style. Also looking for discussion around which existing launcher plugins this could/should replace, if any.
Intro
This is a generalized "search" plugin that can be configured to pass a query from the Pop Launcher frontend to any shell command that returns results (the shell command must return one result per line).
For example, the current "find" plugin (which has 245 lines of rust code), can be implemented in about 10 lines of config, and offers more flexibility to the end user since it becomes trivial to modify the
fdfind
shell args if desired:The
pattern
line indicates when to match the rule. It corresponds with the "prefix" that you type into the launcher frontend. In the above example, the search plugin would begin anfdfind
query if the user starts typing "f" or "find" into the launcher frontend.The
result_name
andresult_desc
settings correspond to the 1st and 2nd lines of each search result (the launcher frontend can show two lines per result). Theresult_name
andresult_desc
settings are optional. By defaultresult_name
is "$OUTPUT", andresult_desc
is blank. Keywords from the query string, and captures from theoutput_captures
regex can be used as needed to format a search result for the user.The
query_command
is the shell command to use as the query function, e.g.fdfind
in our example above. As long as the shell command returns only one line (on STDOUT) per result, any command may be used. For example,ls -1
,apt list
, a shell command that lists your address book contacts, etc.Finally, the
run_command
is the command to run on the active result chosen by the user, i.e. what to do when the user presses "Enter" in the launcher frontend.Note that variables are expanded using shellexpand and therefore can use curly braces and default values, e.g.
${KEYWORD1:-someDefault}
.Example Configurations
Example 1: List hard drives
A launcher command, "drives" that shows a list of block devices:
Example 2: Show running processes
A launcher command, "ps" that lists processes, their PIDs, and how much CPU they are using. This example demonstrates using bash to write a "mini shell script" with a pipe between
ps
andhead
:Example 3: Search apt packages
A launcher command, "apt" that searches for packages using glob syntax of
apt list
, e.g. "apt zu*":To understand the above, it's helpful to know how the shell command
apt list [search_term]
sends results to STDOUT--one per line, in the following format:Note that "Listing... Done" is skipped, because it does not match the
output_capture
's regular expression, which requires that a "/" must be present in the search result line.Example 4: Calculator
The
split
setting is new in the example above: it allows us to split the query using a regular expression. Normally, the query is split into keywords using the default "ShellWords" algorithm, which splits on spaces but also understands things like single and double quotes (treating words enclosed in quotes as a single entity). Here, however, to enter calculator mode with an initial "=" regardless of whether a space follows the "=", we need to split the query differently. In this example, we choose to split on the initial "=", making$KEYWORD1
absorb the remaining equation to be sent toqalc
as input (as well as the frontend as the name).Fixes #164