I am just glad that it is sub-second start time, where with powershell, it was upwards of multiple seconds
Oh My Zsh adds bloat
221–230 of 304 posts
Re: Oh My Zsh adds bloat
#222I'm incredibly impatient with my tools and I've been running omz for many years. I spend my days in tmux/vim and generally run 6-12 shells at a time.
Some quick troubleshooting many years ago narrowed the vast majority of the problem down to the git plugin, especially for large, old repos.
I disabled the git plugin and everything has been fine ever since.
Figured I'd dig deeper and bring back the current branch name without the bloat at some point, but it hasn't bothered me enough to do it.
Re: Oh My Zsh adds bloat
#223Earlier quoted context omitted.
Issue is the cognitive overhead to know 2 distinct shell languages. One you use, and one (almost) everyone else uses. If later isn't of your concern and Fish is all you interact with then no issue whatsoever for interactive or/and scripting use.
Not to be funny, but is POSIX scripting even still relevant? It's well understood that they should only be used for quick and simple tasks, and anything more serious or demanding should be done using something like python instead. But these quick and dirty tasks are very easy for LLM coding agents to do in python. I used to have dozens of shell scripts, each no more than tens of lines long, in my ~/bin/, but I had an…
Do you know how many CI/CD pipelines run on shell scripts?
Another example is small utilities. I wrote one to login to MySQL DBs at work. We have to use Teleport, which I dislike, and it has MFA. So I made a small SQLite DB that has cluster names, endpoints, and secret ARNs (no actual secrets, only metadata), and then wrote a shell function that uses fzf to parse the SQLite DB contents, then ssh tunnels through an EC2 with Teleport to the selected MySQL DB, using expect with a call to 1Pass to answer the password request, and then picks the first available port >=6033 to connect the mysql client. It also tracks the MySQL DB : port assignments in the SQLite DB and waits for the client to exit so it can tear down the ssh tunnel. The only input I have to do beyond selecting the DB is answering a push notification on my phone for MFA.
> replacing 10-LOC shell scripts with Python
The startup time would drive me insane. I love Python, but it’s not great for stuff like that, IMO.
Re: Oh My Zsh adds bloat
#224Shaving milliseconds off of terminal load time seems like a silly thing to optimize for. I notice omz takes a brief moment but it’s never bothered me.
Re: Oh My Zsh adds bloat
#225Shaving milliseconds off of terminal load time seems like a silly thing to optimize for. I notice omz takes a brief moment but it’s never bothered me.
Switching from OMZ shaves a few ms on my very fast desktop machine. It shaves seconds of SSHing into a heavily loaded server.
Re: Oh My Zsh adds bloat
#226This thread feels so foreign to me. I use basic ass vanilla Windows terminal. It’s fine. I also use the vanilla built-in to VSCode terminal. It is also fine. Terminals are such a small, unimportant part of my job I barely even think about them.
Conversely, I spend about 60% of my working day in the terminal, with another 20% in Zed. Wild how much workflows differ, isn’t it?
Re: Oh My Zsh adds bloat
#227I'm incredibly impatient with my tools and I've been running omz for many years. I spend my days in tmux/vim and generally run 6-12 shells at a time. Some quick troubleshooting many years ago narrowed the vast majority of the problem down to the git plugin, especially for large, old repos. I disabled the git plugin and everything has been fine ever since. Figured I'd dig deeper and bring back the current branch name…
Current branch without bloat is to cat .git/HEAD, and if that didn't exist, run git symbolic-ref HEAD. The first is faster and works in the common case where you're in the top of a git repo. In either case, run it through ${branch##*/} to strip down to just the current branch.
I have used this for a long time, never understood how people would put all of git in between them and the next prompt.
Re: Oh My Zsh adds bloat
#228You probably don't need zsh. POSIX shells are holding us back.
Show me an environment where I can interact with my system programmatically, where I can compose together arbitrary tools, and which will never, ever, ever break on me, and I'll switch! My experience with graphical environments has been that they rarely compose, often break, and constantly make arbitrary changes that break my workflow. So every time I try something else I end up coming back to the terminal. But I agr…
> I think it's a real shame we haven't created anything else that does what the terminal does, and I think it's mostly for lack of trying
I'd rather just take terminals a step forward, which I agree hasn't happened due to a lack of trying. But the people who aren't trying are the people who are instead tricking out zsh with plugins. I'm a nushell fan myself but my point here is not
> try nushell
but rather,
> be willing to try things that aren't backwards compatible with `sh`
If more people relaxed on that sticking point, we could actually benefit from the excellent post-POSIX work that has been done. As it is, people are reluctant to try new shells for some reason.
Re: Oh My Zsh adds bloat
#229The tips in the article on enabling vi mode and fzf keybind are worth the read imho
Re: Oh My Zsh adds bloat
#230Earlier quoted context omitted.
> I could spend hours figuring out all those things, This post is explaining how to set up those things. Less than five minutes to read.
Less than five minutes to read but how long to set up my own? The author only showed what he needs/prefers ("Here is my config for starship"). I'll need to navigate the documentation of starship to figure out all those options, which defeats the purpose . Their config documentation ( https://starship.rs/config/ ) already gives me headaches. And from the article > Because cloud services are available globally, I've di…
> Also, most of us are unlike the author, and 0.07s vs 0.38s startup time means no difference.
That's quite likely a workflow thing. If you are popping up new (transient) terminals frequently, then a ~400ms wait time for each adds up and makes the entire machine feel really slow. I'm willing to wait extra half a second for a new terminal -- once -- after I've changed my autocompletion configs (rebuild + rehash takes a while), but if I had to wait for that long every time I hit Win+enter and wait for the terminal to become active, I'd be irritated pretty damn quickly too.
You get conditioned to immediate responses pretty fast.