oh-my-posh: The most customisable and low-latency cross platform/shell prompt
github.com
github.com
My PS1 is based on a 20 line prompt I saw on mastodon. It does git, virtualenv, conda, guix, and some path shortening. 20 lines.
(…and on a very decent Ryzen 7 with NVME)
#!/bin/bash -e
VIRTUAL_ENV="$(realpath "$1")"
export VIRTUAL_ENV
PATH="$VIRTUAL_ENV/bin:$PATH"
export PATH
unset PYTHONHOME
venv="$(basename "$VIRTUAL_ENV")"
if [ "$venv" = ".venv" ] ; then
venv="$(basename "$(dirname "$VIRTUAL_ENV")")"
fi
if [ -n "$venv" ] ; then
debian_chroot="$venv${debian_chroot:+|$debian_chroot}"
export debian_chroot
fi
exec "$SHELL"I moved off omp 2-3 years ago, when it was on v7, and the final straw was that there were enough braking changes that I had to version-pin.
If I used bash-like shells more than once a month, I could use the same starship config in bash.
Y'all, I don't like the update check either. Self-updating behavior and similar crap sucks in all apps, imo, and it seems especially out-of-place in command-line prompts like this one. But a lot of people seem to like it, especially on operating systems that don't have first-class package management. I'd turn it off, and I'd expect a decent free software distribution to disable it by default in their packages.
At the end of the day, this is the work of some guy to try to make his own shell prompt delightful to him. It's not a slow PowerShell module, although a project of the same name used to be that-- it's a younger cousin of Starship. And it's pretty good.
All of the other fresh grad hires tried to use Ubuntu systems with a Windows XP mindset.
Having a central bank really is a great evil.
We are a business, not a charity daycare, we do have to actually *judge* employees we hire on their merits.
> number of startups do use Mac
Modern day macOS is "fine" for the people who will be doing everything they do in Google Chrome.
The organizations I tend to frequent are of very high talent density, hence a software developer who forthcomingly prefers macOS and is clueless about *software* (ie operating systems) in a fundamental way is looked down on (and rightly so) by the higher echelon of talent.
> All of the other fresh grad hires tried to use Ubuntu systems with a Windows XP mindset.
I've written about this on HN before, but the fact is that for many, having a pleasant experience on the terminal is a prerequisite for them taking the time to actually learn the basics. The the terminal emulator isn't a pleasant, cozy place to work in even for newbies, people won't stick around to learn fundamentals like exit statuses or job control.
By the same token, there are a lot of people with little previous command-line experience who respond very well to some friendlier defaults in their shell, and become much more interested in further customizing their experience and learning about the Unix environment.
I will go out of my way to delete this from a codebase.
I will go out of my way to block the url to github, and remove this from package manifests.
I will ensure that anything that would break oh-my-posh is a fundamental part of the software.
Nothing against oh-my-posh, its just too slow.
What I actually do hate are people, the kind of people who try to mandate and even further depend on oh-my-posh semantics. Or even more generally mandate cosmetic things in a generalized development environment. Your pretty colors and ligatures are jarring noise that actively destroys my attention and focus.
I value my terminal experience heavily, oh-my-posh has very much so been useless to an active deterrent in development to me due to it's slowness and poor defaults. Cross platform. But by far my worst experience is Windows.
And there is only so much you can blame on Windows Terminal (and other emulators on Windows) being slow due to all the jank on supporting so many bad algorithms, bad internal representation, codepoints, and encodings.
I especially hate the git "support". A moderately worn git repo will show you a noticeable slow down in standard operations just due to the number of objects, references, etc. that exists from the lifetime of active development. Yet rev-parse is effectively depended on to write out the branch, commit hash, etc.
There's more, far more. I am very unlikely to change my mind too. Maybe this software is for people who only touch the terminal precisely when they have no other option. And maybe I'm just too far from that demographic.
I can only rationalize these things happening as inexperience, too eager to please. I'd hate for these things to occur only for job retention tactics for the increased bus factor. But they are very much so real.
I've seen it happen in multiple instances with moves to generalized development containers/workspaces.
If you don't think I'm reputable, you can go and ask the man who made oh-my-posh where its actively used in his company and why.
You can also ask someone who works in any of those orgs if oh-my-posh makes an appearance and what happens if you try and remove it from the standard checkout/build process the average engineer goes through.
As for specifics, can't help you there, I was never the person who added the dependency. And I am distant to the acute requirements for oh-my-posh were, if there were any (which I am absolutely confident there was not, but an inexperienced/misinformed engineer could conjure about any number of reasons). I know specifically my short interactions with BI specifically trying to rid myself of oh-my-posh through regular uninstall + blackholing the download would lead to failures.
I don't see how that translates into gen dev environments either.
I would love to see the use case for a dev env that requires OMP (or OMZ, or Prezto, or even Starship) to be a functioning dev env.