[BUG] EWW daemon expect to run on default $PATH

[SamuelHDieterich]

Checklist before submitting an issue

• I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
• I have specifically verified that this bug is not a common user error
• I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

Apparently, the EWW daemon expects to run on a "default $PATH" (such as /usr/local/bin/), at least when it is not manually run using a terminal emulator. When I tried to spawn the daemon on different autostart manners (exec-once on Hyprland, systemD service, .zprofile or .zlogin), it always failed or was not properly working¹. My specific window was not working as well to properly start the daemon by itself when I open it using a keybinding.

I think the issue is the path for two reasons:

1. On one of my logs, I got a message: /bin/sh: line 1: eww command not found

Nov 05 20:25:08 tesla eww[1831]: ┏━━━━━━━━━━━━━━━━━━━━━━━┓
Nov 05 20:25:08 tesla eww[1831]: ┃Initializing eww daemon┃
Nov 05 20:25:08 tesla eww[1831]: ┗━━━━━━━━━━━━━━━━━━━━━━━┛
Nov 05 20:25:08 tesla eww[1831]:     
Nov 05 20:25:08 tesla systemd[868]: Finished eww.service.
Nov 05 20:25:08 tesla eww[1831]:  2023-11-05T23:25:08.689Z WARN  eww::config::system_stats > Failed to get/calculate uWh: the total_avg value of the battery magic var will probably be a garbage value that can not be trusted.
Nov 05 20:25:08 tesla eww[1831]:  2023-11-05T23:25:08.753Z INFO  eww::ipc_server           > IPC server initialized
Nov 05 20:25:19 tesla eww[1831]:  2023-11-05T23:25:19.909Z INFO  eww::app                  > Opening window powermenu
Nov 05 20:25:22 tesla eww[2015]: /bin/sh: line 1: eww: command not found
Nov 05 20:25:23 tesla eww[1831]:  2023-11-05T23:25:23.597Z INFO  eww::app                  > Closing gtk window powermenu

2. When I moved the executable to /usr/local/bin/eww, all the problems magically disappeared.

¹ By properly working, I mean at least the eventbox widget was not doing what I programmed it to do onclick and onhoverlost.

Reproducing the issue

1. Manually compile EWW. In my case, I used the wayland feature since I'm on Hyprland.
2. Copy the eww executable to a folder that is not part of the "default $PATH" such as ~/.local/bin/.
3. Try to run <PATH TO EWW>/eww daemon on your autostart script, such as the ones I mentioned in the description section.
4. Check if the daemon is actually running (<PATH TO EWW>/eww ping or <PATH TO EWW>/eww logs) or try to open a window that uses, for instance, eventbox and check if it is working as expected.

Expected behaviour

I would expect one of two things.

At the very least, it should be clearer in the documentation that to avoid these sorts of issues it is recommended to have the eww executable on a path such as /usr/local/bin for those who manually compiled it.

However, if I'm actually right and the issue is with the path, I would prefer to have eww take the first argument of the command to save it and use it internally if necessary to trigger itself. In other words, instead of calling eww, store "$0" and use it later if convenient. Unfortunately, I must admit that it sounds very unlikely that this is the root source of the problem, otherwise, it is quite an odd decision to call for internal functions of the code by spawning shell scripts to itself.

Additional context

System

• Distro: Arch Linux
• WM: Hyprland
• EWW Instalation: manually compiled with the wayland feature
• EWW executable path: ~/.local/bin/eww

Ways I tried to autostart the eww daemon

• Hyprland exec-once: I tried just calling it using the full path, using an auxiliary script, and adding sleep between the commands and nothing helped. I even thought at first that it was an Hyprland issue).
• SystemD service: I tried creating a simple service to run on login to fix the issue (that I thought was caused by Hyprland).

[Service]
Type=oneshot
RemainAfterExit=true
StandardOutput=journal
ExecStart=~/.local/bin/eww daemon
ExecStop=~/.local/bin/eww kill

[Install]
WantedBy=default.target

• .zlogin: I'm using ZSH as my default shell, so I tried invoking the eww daemon from it as well.

EWW window

eww.yuck

(defwindow powermenu
    ;; :monitor 1
    :namespace "eww_powermenu"
    :class "powermenu"
    :geometry (geometry :x "0%"
                        :y "0%"
                        :width "100%"
                        :height "100%"
                        :anchor "top center")
    :stacking "overlay"
    (powermenu_buttons))

(defwidget powermenu_buttons []
    (eventbox
      :class "powermenu-background"
      :onclick "eww close powermenu"
      :onhoverlost "eww close powermenu"
      (box :class "powermenu-buttons"
           :orientation "horizontal"
           :spacing 10
           :halign "center"
           :valign "center"
           :hexpand true
           :vexpand true
           :space-evenly true
           (button
              :class "shutdown"
              :onclick "systemctl poweroff"
              "")
           (button
              :class "reboot"
              :onclick "systemctl reboot"
              "")
           (button
              :class "suspend"
              :onclick "systemctl suspend && eww close powermenu"
              "")
           (button
              :class "hibernate"
              :onclick "systemctl hibernate && eww close powermenu"
              "󰒲")
           (button
              :class "screen-off"
              :timeout "2s"
              :onclick "hyprctl dispatch dpms off && eww close powermenu"
              "󰶐")
           (button
              :class "lock"
              :timeout "2s"
              :onclick "eww close powermenu && swaylock"
              "")
           (button
              :class "logout"
              :onclick "hyprctl dispatch exit"
              "󰍃"))))

I use a keybinding to open the window with this command: <PATH TO EWW>/eww open --toggle --screen 0 powermenu. That way, it opens the window on my active monitor.

Note

I know I marked this issue as a bug although I was able to solve it. However, since the behavior is quite odd and more users may have a similar issue, I think, at least for documentation purposes, this issue may help someone to solve their problem with this amazing software.

[Lanpingner]

Hi Dear

I don't understand your issue
If you compile any program in any lang it creates a build dir (usually like rust)
Usually they create a make file which help with compiling then installing the executable to the correct place
Example

make build runs 'cargo build --release'
make install copies the executable to the correct place (usually in the /usr/local/bin).

As far as i know cargo has no option like this you need to do this yourself (copy the files)

For the issue to be solved i will try to create a make File

[SamuelHDieterich]

Hey, @Lanpingner, thank you for the reply.

Actually, my problem is not to automatically add the executable to /usr/local/bin, which would be interesting though. In a nutshell, the issue is that - for me at least - the eww daemon seems to not work properly when the executable is not located in the $PATH (even if I use the absolute path to invoke it) when triggered by an autostart script (such as the ones I listed in my first message).

If I have the time, I could try to check the source code to find something that would indicate that this is indeed the root of the problem here. If you can replicate the issue, that would be great as well, so we could minimize the chance that the issue is isolated to my case.

[Lanpingner]

Ohh got it,
I can tell my experience, I also use Hyprland and i am facing no issue with starting eww with exec-once
This is the command i run in a bash script
killall eww
eww daemon
eww open topbar
eww open bottombar

Although my eww compiled folder is in the $PATH
The Reason why it not work might be that eww looks for the lib files or some additional files in the $PATH and if you just place the executable there it will miss the files, or its the rust linker. These are just speculations i need to take closer look to rust compiling and finding libs and dependencies how he looks them up

[viandoxdev]

If I understand your issue, this could be solved by having eww prepend its own binary path to the PATH environment variable when executing commands triggered by events, this shouldn't be that complicated code wise, though it should be documented as this could be confusing.