Pipe operator not working in deflisten?

[jeancf]

I am sure I am missing something huge here but I can't figure out what.

I am trying to build a bar for niri. I want to grab some streaming even data with the niri msg executable. When I call it inside the deflisten variable I see the value last event being constantly updated in the widget as expected. But if I try to pipe its output into a grep command (e.g. to only display focus change events) the display widget is never updated and keeps showing the :intial value of the deflisten variable.

Concretely, niri msg -j event-stream works fine inside deflisten; niri msg -j event-stream | grep WindowFocusChanged works as expected on the command line but NOT inside deflisten.

Can somebody please enlighten me? I am stuck and I really want to get eww working. Thanks!

Minimalist use case:

(defwindow panel
  :monitor 0
  :geometry (geometry :x "0%"
                      :y "5px"
                      :width "99.4%"
                      :height "30px"
                      :anchor "top center")
  :stacking "fg"
  :exclusive "true"
  (box
    (active-window-name)
  )
)

(defwidget active-window-name []
  (label
    :text "${win_id}"
  )
)

(deflisten win_id
  :initial "-"
  `niri msg -j event-stream`
   ; using `niri msg -j event-stream | grep WindowFocusChanged` instead never updates the initial value
)

[silicon-salamander]

The pipe operator only does something special when the command line is interpreted by a shell (e.g. bash, zsh, fish) and EWW doesn't run the command through a shell. To get that to work you can wrap the command line with a call to bash like this:

(deflisten win_id :initial "-" `bash -c "niri msg -j event-stream | grep WindowFocusChanged"`)

[jeancf]

Thanks for the suggestion, I really wish it worked but the result is the same.

When I use niri msg -j event-stream | grep WindowFocusChanged I see that both niri and grep processes are running in an sh shell:

\_ /usr/bin/eww daemon --no-daemonize
|   \_ sh -c niri msg -j event-stream | grep WindowFocusChanged
|       \_ niri msg -j event-stream
|       \_ grep WindowFocusChanged

When I use bash -c "niri msg -j event-stream | grep WindowFocusChanged" both run in a bash shell:

\_ /usr/bin/eww daemon --no-daemonize
|   \_ bash -c niri msg -j event-stream | grep WindowFocusChanged
|       \_ niri msg -j event-stream
|       \_ grep WindowFocusChanged

But in neither case do I see an output.

I also tried to move the command in a .sh file and run it with sh and bash with the same result.

[silicon-salamander]

Oh huh, your right. I should have tested my assumption lol.
Another thing to try is adding the --line-buffered option grep, so that it outputs a line as soon as it matches. I just remembered I had that in some of my scripts.

[hypernova7]

I assume that the command niri msg -j event-stream is like tail that outputs values ​​when there is a change. In that case that is not how you should use it with grep, but like this:

(deflisten win_id :initial "-" `bash -c "niri msg -j event-stream | while read -r line; do echo "$line" | grep WindowFocusChanged; done"`)

It would be advisable to create a script to make it easier and more understandable when changing something.

Create a new file called window_focus_changed.sh

#!/usr/bin/env bash
niri msg -j event-stream | {
  while read -r line; do
    echo "$line" | grep WindowFocusChanged
  done
}

Then just give them the necessary permissions with chmod u+x window_focus_changed.sh

(deflisten win_id :initial "-" `./path/to/window_focus_changed.sh`)

[silicon-salamander]

Is there an advantage to doing it this over using the --line-buffered option?
grep by itself does work well for long running streams.
For example one of my scripts has this:

pactl subscribe | grep --line-buffered "Event 'change' on"

This outputs the lines immediately as they are matched instead of the normal buffering that grep will do.

[hypernova7]

You can try

[silicon-salamander]

I just tried your idea in my script and it worked the same. I'm not sure how I would test performance in this case.
Also I didn't mean to attack your solution or anything. I just like getting to the bottom of things and learning the pros and cons of different solutions.

[hypernova7]

Don't worry, that's what being a Linux user is all about.

[jeancf]

Thanks a lot to both of you for your help. Both solutions work but I marked the one from @SylvAbdomen as answer because it is more concise.

You made my Sunday, thanks !