Something that “kinda works” actually does work. Fixing the edge case when it is actually a problem may actually save time compared to spending extra time up front on things that might never be a problem.
I should have been clearer about that: but I'm not talking about theoretical edge cases. I'm talking about "I tried to run it and it doesn't work", or worse (e.g wrong behaviour).
Shell scripts are often the peak of "works on my machine".
The problem mostly stems from the fact that MacOS folks don't have compatible Unix utils to the Linux folks, and the majority of developers are on MacOS but everything deploys on Linux. The easiest way to fix this is to install GNU utils on mac so you're using the same bash and system tools everywhere.
That is one problem, but there are others: assuming things like current working directory, assuming certain tools are installed and failing badly when it's not (e.g. doesn't do anything but no error, has the wrong behaviour and no warning), and things like that.
I’d agree: every critical shell script should work in all the places it currently needs to run. But, I think it’s reasonable to iterate here towards perfection: every time a new employee shows up or new environment comes up is a chance to uncover these problems and fix them.
There’s a balance here between solving the problem you actually have (YAGNI) and responsible engineering. Obviously you should test that your code works as expected in all the current environments but, sometimes, ensuring that all the edge cases are handled is just over-engineering.
Shell scripts are often the peak of "works on my machine".