This is neat but the examples comparing the tool against piping grep seem to counter the argument to me. A couple of pipes to grep seems much easier to remember and type, especially with all the quotes needed for psc. For scripts where you need exact output this looks great.
I'm not convinced with the need to embed CEL. You could just output json and pipe to jq.
Thanks for including so many examples! Perhaps include one example output. Other than mention of the optional '--tree' parameter, it's unclear if the default result would be a list, table, JSON, etc.
> psc uses eBPF iterators to read process and file descriptor information directly from kernel data structures. This bypasses the /proc filesystem entirely, providing visibility that cannot be subverted by userland rootkits or LD_PRELOAD tricks.<p>Is there a trade off here?
Their first example is bad:<p><pre><code> ps aux | grep nginx | grep root | grep -v grep
</code></pre>
can be done instead (from memory, not at a Linux machine ATM):<p><pre><code> ps -u root -C nginx
</code></pre>
which is arguably better than their solution:<p><pre><code> psc 'process.name == "nginx" && process.user == "root"'</code></pre>
The commands in their example are not equivalent. The ps | grep thing searches the full command line including argument while ps -C (and, presumably, the psc thing) just returns the process name.<p>Should you for some reason want to do the former, this is easiest done using:<p><pre><code> pgrep -u root -f nginx
</code></pre>
which exists on almost all platforms, with the notable exception of AIX.<p>Their other slightly convoluted example is:<p><pre><code> psc 'socket.state == established && socket.dstPort == uint(443)'
</code></pre>
which is much more succinct with:<p><pre><code> lsof -i :443 -s TCP:ESTABLISHED</code></pre>