Questions regarding zsh startup files and the syntax for calling a shell script via a Niri keybind

[sondhg]

Hello, I liked your dot-screenshot shell script, so I copied it to my own ~/.local/bin. I binded it to a Mod+S keybind for Niri, same as you. However, the syntax I had to use inside ~/.config/niri/config.kdl had to be either spawn "~/.local/bin/dot-screenshot" "region" or spawn-sh ~/.local/bin/dot-screenshot region". I mean, I had to use the absolute path to the screenshot shellscript. I see you only have to use spawn "dot-screenshot" "region". I like short lines of code a lot more than long ones, so I'm curious how you were able to make it work.

There are some differences between your configs and mine, I'll list them here:

Yours

• export PATH="${HOME}/.local/bin:${PATH}" inside ~/.zprofile
• spawn "dot-screenshot" "region" inside ~/.config/niri/config.kdl

Mine

Initial

• path=(~/.local/bin $path) inside ~/.zshrc.
• spawn "~/.local/bin/dot-screenshot" "region" inside ~/.config/niri/config.kdl

This uses the absolute path to the screenshot script, so of course it works.

First change

• Still path=(~/.local/bin $path) inside ~/.zshrc
• spawn "dot-screenshot" "region" inside ~/.config/niri/config.kdl

Not working.

Second change

• Remove path=(~/.local/bin $path), include export PATH="${HOME}/.local/bin:${PATH}" inside ~/.zshrc
• spawn "dot-screenshot" "region" inside ~/.config/niri/config.kdl

Not working.

Third change

• Include export PATH="${HOME}/.local/bin:${PATH}" or path=(~/.local/bin $path) inside~/.zprofile instead of ~/.zshrc
• spawn "dot-screenshot" "region" inside ~/.config/niri/config.kdl

It works!

Conclusion

So what I figured out is that I had to modify the PATH env var or the path array (pretty much the same thing) inside ~/.zprofile instead of ~/.zshrc. I don't know why, but I had to. Normally, I like to keep every zsh config in ~/.zshrc, I don't want to touch my ~/.zprofile file ever, because I use https://github.com/romkatv/zsh4humans and its documentation has this section:

When you start Zsh, it automatically sources ~/.zshenv and ~/.zshrc. The former bootstraps Zsh for Humans, the latter is your personal config. It is strongly recommended to keep all shell customization and configuration (including exported environment variables such as PATH) in ~/.zshrc or in files sourced from ~/.zshrc. If you are certain that you must export some environment variables in ~/.zshenv, do it where indicated by comments.

Zsh supports several additional startup files with complex rules governing when each file is sourced. The additional startup files are ~/.zprofile, ~/.zlogin and ~/.zlogout. Do not create these files unless you are absolutely certain you need them.

For the cases that didn't work for me (cases where I include PATH code inside .zshrc instead of .zprofile), I think possibly my ~/.local/bin was somehow not in the PATH, so Niri couldn't find the dot-screenshot script? I'm not entirely sure, because whenever I launch a terminal and run echo $PATH | tr ':' '\n' | grep '/home/sondhg/.local/bin', it does exist in the PATH (zsh is my login shell).

I just want to ask if you ever had trouble with this kind of "calling a shell script from a WM" problem. I've just recently switched from a DE to a WM and started to learn how to write shell scripts, and this has been quite a headache for me.

[nickjj]

Hey,

If you set it in your PATH, you should be able to run dot-screenshot region from your shell, were you able to confirm that?

I don't know how you launch niri but I'm using uwsm. If you install these dotfiles it adds this to what's basically the bottom of your .zprofile file if uwsm check may-start; then exec uwsm start -- niri.desktop; fi. The PATH is defined in this same file.

When this executes, as far as I know it will inherit whatever your shell has available and PATH should be defined already which will allow niri to also "see" your PATH and now the key bind should work.

Btw, I also have a satty config at https://github.com/nickjj/dotfiles/blob/master/.config/satty/config.toml which you may want to carry over if you like these preferences. In my niri config there's also screenshot-path null to prevent its screenshot tool from writing things to disk directly, since satty handles that now.

As for zprofile vs zshrc. The main difference is zshrc will execute every time you open a new terminal session where as zprofile will only execute once when you login. I try to keep my zprofile loaded up with things that won't change often like defining a number of env vars and launching niri itself. You can also source your zprofile in your current terminal if you wanted to test something new without logging out and back in.

Going back to how you launch niri, if you had PATH in zshrc but launch niri from a script that executes before that, that could explain why niri wasn't able to see your PATH.

[sondhg]

As for zprofile vs zshrc. The main difference is zshrc will execute every time you open a new terminal session where as zprofile will only execute once when you login. I try to keep my zprofile loaded up with things that won't change often like defining a number of env vars and launching niri itself. You can also source your zprofile in your current terminal if you wanted to test something new without logging out and back in.

Yes I know this. I think the root of my problem is that Niri doesn't seem to "see" my full PATH, like you said.

If you set it in your PATH, you should be able to run dot-screenshot region from your shell, were you able to confirm that?

Yes, running the script from a shell always works.

Btw, I also have a satty config at master/.config/satty/config.toml which you may want to carry over if you like these preferences. In my niri config there's also screenshot-path null to prevent its screenshot tool from writing things to disk directly, since satty handles that now.

Yes I did copy your satty/config.toml. I also use screenshot-path null because most of the time I just copy screenshots to clipboard for quick sharing.

I don't know how you launch niri but I'm using uwsm.

I launch Niri via a display manager, ly.

Going back to how you launch niri, if you had PATH in zshrc but launch niri from a script that executes before that, that could explain why niri wasn't able to see your PATH.

Now you got me thinking about how a display manager actually starts a WM, and what the order for sourcing files like .zshrc and .zprofile is. I'll take a look into documentation for these.

Thank you for the help! This isn't a big problem at all, I just prefer to write less code in my config files if possible. When there are dozens of shell scripts, typing ~/.local/bin again and again gets tiring haha

[nickjj]

Now you got me thinking about how a display manager actually starts a WM, and what the order for sourcing files like .zshrc and .zprofile is. I'll take a look into documentation for these.

I don't use a display manager but when I log in through tty1 directly, zprofile is loaded and then zshrc is loaded after, AFAIK zenv gets loaded once before zprofile.

When there are dozens of shell scripts, typing ~/.local/bin again and again gets tiring haha

Yeah definitely. I'm guessing there has to be a way to launch it in a way that works for you, while continuing to use your display manager.