Fuck it, .zshrc
it is.
Image transcription:
- Top text: I STILL DON’T KNOW WHAT SHOULD GO IN .*RC VERSUS .*PROFILE
- Bottom text: AND AT THIS POINT I’M AFRAID TO ASK
- Korthrun ( @korthrun@lemmy.sdf.org ) 26•2 months ago
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.
- Gamma ( @gamma@programming.dev ) English1•2 months ago
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.
- Korthrun ( @korthrun@lemmy.sdf.org ) 1•2 months ago
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.
- Gamma ( @gamma@programming.dev ) English1•2 months ago
Yeah, I’d write this as a single
update
script with options toupdate vimplugins
orupdate pkg
orupdate 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.
- Korthrun ( @korthrun@lemmy.sdf.org ) 1•2 months ago
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.
- tyler ( @tyler@programming.dev ) 18•2 months ago
Switching to Fish was the best decision I ever made in my terminal. Besides using tmux.
- RecluseRamble ( @RecluseRamble@lemmy.dbzer0.com ) 7•2 months ago
Isn’t the POSIX incompatibility a major roadblock when scripting?
- Hack3900 ( @Hack3900@lemy.lol ) 15•2 months ago
Not really, you can make .fish scripts or call “bash script.sh” when it’s more appropriate to be posix compliant
- tyler ( @tyler@programming.dev ) 1•2 months ago
Not really. I hate writing bash scripts anyway so I usually script whatever I need in Ruby which is far better at scripting than any posix script ever will be, and even when I do need to run a bash script I still can or just shell down into bash or zsh if I really really need to. But that’s like once a year.
- CodeBlooded ( @CodeBlooded@programming.dev ) 3•2 months ago
Alright stranger, let’s hear it. What is it about Fish that you love so much?
I’ve been generally happy with bash or zsh, pretty much whatever is installed by default (and I honestly don’t know the difference between the two I just mentioned 😬).
- The Cuuuuube ( @Cube6392@beehaw.org ) English5•2 months ago
Zsh has more features and customization options than bash. Fish has a ton of convenience features at the cost of POSIX compatibility (which many view as a good thing)
- tyler ( @tyler@programming.dev ) 4•2 months ago
Once upon a time I was the person that was constantly messing with my shell. I would performance tune it, try out new plugins weekly, change my config often. It honestly became a huge waste of time. Since switching to fish I literally haven’t spent any time configuring it at all, besides adding in the fzf plugin and the fzf-marks plugin. It just works. And it has all of the same features that everyone adds to zsh with plugins straight out of the box.
If you’re happy with the default in bash or zsh then you will be even more happy with the default in fish, as it’s just much much more user friendly (which is why so many people add so many plugins to bash and zsh: to make it more user friendly). You can even configure it (even the colors) with a web interface! No mucking about in text files if you don’t want to.
I have sort of been eyeing fish on and off for years. I enjoy my oh my zsh setup and have it somewhat customized. I use a modified version of the funky theme. (I can share if interested.) When I’m at work I don’t try new things that might affect my productivity (like trying a new shell) and when I have motivation to do techy stuff in my free time I really need to utilize it to do what I want because my focus really meanders.
- tyler ( @tyler@programming.dev ) 3•2 months ago
I was the person who used every kind of zsh package manager that existed. I even had performance tweaks for some because they were too slow for me. I didn’t even use oh my zsh because it was too slow, and I had hundreds of customizations and maybe 30 plugins.
I no longer needed any of the plugins except fzf and fzf-marks when I switched to fish. It really did simplify my life a whole lot. I don’t ever mess with configs anymore.
- rooroo ( @rooroo@feddit.de ) 1•2 months ago
That’s fair. But look at it this way, when you’re at work you’re being paid for it, and you might eventually improve your productivity.
Also, you can have a look at oh my fish, it’s an alternative to omz I used before switching to starship.
I feel pretty productive with CLI stuff. Fish does look nifty though. I’ll give it a shot sometime. Oil has been intriguing too, I’ve enjoyed reading updates about it over the years back on r/programming. https://www.oilshell.org/cross-ref.html?tag=OSH#OSH
- Crow ( @Crow@lemmy.blahaj.zone ) 9•2 months ago
Afaik the difference is whether a session is interactive or not, and non-interactive ones don’t source the rc
But what would I want in a login shell that I don’t also want in a non login shell?
- Crow ( @Crow@lemmy.blahaj.zone ) 2•2 months ago
Presumably just to get rid of unnecessary stuff that would slow down the start of all bash instances. Also aliases that could fuck with scripts
This really triggered an itch in me and I’m having trouble finding answers. It sounds like
.profile
might get sourced by your desktop environment when you log in but I’m having trouble finding out one way or the other. Every search I make just ends up with people asking about shells.
- Gamma ( @gamma@programming.dev ) English6•2 months ago
When in doubt,
~/.zshrc
. It’s the right choice 99% of the time. Otherwise, there’s a chance you fuck up scripts you’ve installed which assume no shell options have been changed in non-interactive contexts. - BeigeAgenda ( @BeigeAgenda@lemmy.ca ) 4•2 months ago
What about what I do: Just add
. ~/.bash_BeigeAgenda
at the bottom of one of the files, for all my own crap. - katy ✨ ( @cupcakezealot@lemmy.blahaj.zone ) 2•2 months ago
- Crow ( @Crow@lemmy.blahaj.zone ) 1•2 months ago
You’re aware of what the * does? And of people using other shells?