Skip to Content

POSIX Compliance and My Life

A few months ago, I was working in my bash terminal when I noticed my colleague behind me with iTerm2 open and many more fancier colors than what I have. I went over and asked him about his shell environment. “Oh yeah, this isn’t bash, this is fish.” Apparently, the shell itself automatically saves your browsing history so that you can tab complete to the repository you want. It also has a form of Git integration so that the command prompt shows you what branch you are on. It was quite amazing.

A short while after that, I see another colleague using something similar, and when I go over and ask her about what shell she is using, she replies, “Oh yeah, this isn’t bash, this is zsh”. It looked like pretty much the same thing - ghosting, git integration, and much more pleasant to use than bash.

So I tried to install fish and zsh on my machine. It failed. I have a bunch of bash scripts that I run on startup, and those break because 🎉 they’re not POSIX-compliant! This isn’t just my system, it’s also for a bunch of helper scripts that I wrote for our repositories as well. So I went ahead and tried to find out how to avoid this.


So apparently, there’s this thing called POSIX. I Googled it and found this Stack Overflow post which describes in detail what POSIX is. It’s an API. Of course it’s an API. As far as I can tell, it’s meant to increase interoperability between different types of *nix systems, like Linux and macOS. That’s why when you go to the shell in both of these systems, it looks super familiar. That’s also why Windows, which is not POSIX-compliant at all, looks so freaking alien.

Apparently, no shell really is fully POSIX-compliant. They all have their own superset of commands that may make porting difficult. Other people have run into this issue as well, so many in fact that people build out linters for shell scripts to ensure that portability isn’t a concern. ShellCheck looks pretty interesting. I should make this part of my ecosystem.