Closed mattbishop closed 1 year ago
Suggestion for using the replay command:
evently selector:replay \
-n <entity> \
-e <event> -e <event> \ #multiple allowed, they are ORed
-k <key> -k <key> # Key to select for, also allows multiple. They are also ORed
--after <eventid>
-- limit <number>
Instead of having keys and events appear multiple times, we could also use a pipe (|
) to seperate them and indicate 'OR' more clearly.
This looks good, the multiple -e
and -k
approach is a bit odd. What about accepting a JSON5 list instead? -k [key1,key2,"key,3"]
and single key could be unwrapped? -k key1
[
does have a special meaning in most shells, so it would look more like:
-k \[\"key1\", \"key2\"\]
or
-k '["key1", "key2"]'
But that works for me. I'd just detect if the key starts with a [
and then assume it's an array.
There is plenty of precedent with repeating arguments though. Even for example git commit -m
can appear multiple times for multiple paragraphs, ffmpeg -i
appears multiple times for multiple input files; so up to you!
Right. That’s not a great look. Ok, multiple -k items it is!—Matt BishopOn Jun 10, 2023, at 11:16 AM, Evert Pot @.***> wrote: [ does have a special meaning in most shells, so it would look more like: -k [\"key1\", \"key2\"]
or
-k '["key1", "key2"]
But that works for me. There is plenty of precedent with repeating arguments though. Even for example git commit -m can appear multiple times for multiple paragraphs for example, so up to you!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
One pulls events out of Evently with the Selectors API: https://preview.evently.cloud/selectors
We have two types of selectors:
Each of these has similar affordances for result limiting and starting points. This command would accept appropriate params and display the results in a "nice" way. Some kind of table, ideally with colorized formatting of the meta and data values.