It’s all about context. If you write a convenience function and put it in zshrc, scripts you run from the cli will not have access to the function as defined in zshrc. Same with aliases added by zsh plugins etc.
If you need “the thing” on the command line, zshrc. If you also need it in scripts you run from the cli, toss it in the profile file.
ETA: I personally keep the functions I want to access from scripts in .zshenv as I recall reading that this file is ALWAYS sourced.
What kind of functions do you write which you share between your scripts? Generally if I’m wanting to reuse a non-trivial function, I extend the functionality of the first script instead.
All of the repos for my GitHub sourced vim plugins live under one parent directory. I symlink to them from ~/.vim
One example is a simple function that pushes the top level repo directory onto my dir stack and then runs a loop where it pushes each subdir into the stack, runs “ggpull” then pops back to the top level repo directory. ggpull is an alias added by the zsh git plugin. After all repos have been updated it pops back to my original pwd.
I run this as part of my “update all the things” script but sometimes I also want to run it in demand from the cli. So I want this function in all scopes and I want it to have access to “ggpull” in all of those scopes.
I also “misuse” timewarrior a bit and use it to time things like “how much time do I spend waiting for salt to run”. That has its own timewarrior db and a wrapper function for pointing the command at said db. I use this in both login and non login shell contexts.
zshenv’s selling point isn’t necessarily that your typical functions are available across scripts (though that can be neat, too – I source aliasrc as well as an utils script file in my shell config) – it’s that it’s there for non-interactive shells too, whereas zprofile is only applied for login shells (and zshrc only for interactive ones).
So for example, I could open a command in my editor of choice (Helix’s :sh for me), and if I define stuff using the zshenv, all of my aliases etc. are right there. I just have to avoid naming conflicts for script function names if it’s the default shell, but that’s pretty easily done.
It’s all about context. If you write a convenience function and put it in zshrc, scripts you run from the cli will not have access to the function as defined in zshrc. Same with aliases added by zsh plugins etc.
If you need “the thing” on the command line, zshrc. If you also need it in scripts you run from the cli, toss it in the profile file.
ETA: I personally keep the functions I want to access from scripts in .zshenv as I recall reading that this file is ALWAYS sourced.
What kind of functions do you write which you share between your scripts? Generally if I’m wanting to reuse a non-trivial function, I extend the functionality of the first script instead.
All of the repos for my GitHub sourced vim plugins live under one parent directory. I symlink to them from ~/.vim
One example is a simple function that pushes the top level repo directory onto my dir stack and then runs a loop where it pushes each subdir into the stack, runs “ggpull” then pops back to the top level repo directory. ggpull is an alias added by the zsh git plugin. After all repos have been updated it pops back to my original pwd.
I run this as part of my “update all the things” script but sometimes I also want to run it in demand from the cli. So I want this function in all scopes and I want it to have access to “ggpull” in all of those scopes.
I also “misuse” timewarrior a bit and use it to time things like “how much time do I spend waiting for salt to run”. That has its own timewarrior db and a wrapper function for pointing the command at said db. I use this in both login and non login shell contexts.
Yeah, I’d write this as a single
updatescript with options toupdate vimpluginsorupdate pkgorupdate all.I see that you want it to be a function so you can get the chdir as a side effect, but mixing that with updating doesn’t make sense to me.
zshenv’s selling point isn’t necessarily that your typical functions are available across scripts (though that can be neat, too – I sourcealiasrcas well as anutilsscript file in my shell config) – it’s that it’s there for non-interactive shells too, whereaszprofileis only applied for login shells (andzshrconly for interactive ones).So for example, I could open a command in my editor of choice (Helix’s
:shfor me), and if I define stuff using thezshenv, all of my aliases etc. are right there. I just have to avoid naming conflicts for script function names if it’s the default shell, but that’s pretty easily done.