3 ms·
> This is not a rousing endorsement of the Unix shell environment. It's surely not. The question wasn't how to rewrite the shell environment to be more "endor
by ajross 1y ago
> This is not a rousing endorsement of the Unix shell environment.
It's surely not. The question wasn't how to rewrite the shell environment to be more "endorseable", though.
The point is that we have a half century (!) long history of writing code to this admittedly fragile environment, with no way to audit usage or even find all the existing code (literally many of the authors are retired or dead).
So... it's just not a good place to play games with "Look Ma, I rewrote /usr/bin/date and it's safe now!" Mess with your own new environments, not the ones that run the rest of the world please.
- JuniperMesos 1y agoMaybe it's more important to rewrite half a century of poorly documented and specified shell scripts that are so embedded that their existence gets in way of rewriting fundamental Unix command line utilities, than it is to rewrite those utilities themselves. Any time someone makes the claim "we shouldn't touch this code, it's fragile" that state of affairs is itself bad. Our free software source code shouldn't be some poorly understood black box that we're afraid to touch for fear of breaking something, and if it is that is something we should fix.
- ajross 1y ago> Maybe it's more important to rewrite half a century of poorly documented and specified shell scripts Sounds like a plan. Let me know when you're done, and then we can remove fgrep.
- JuniperMesos 1y ago[dead]