Benchmarking shell pipelines and the Unix “tools” philosophy

Re:Benchmarking shell pipelines and the Unix “tools” philosophy by wahern on Tuesday January 07, 2020 @05:54PM (#21986078)

There would be less trivia to memorize if the command behaviors and options were more consistent. You may not be able to achieve that at the edges, where new commands and options are added, but you can always go back and clean things up.

For example, the cut(1) command is intended to do precisely what his f script does. But it's inconvenient because unlike many other commands it (1) doesn't obey $IFS and (2) the -d delimiter option only takes a single character. This could and should be remediated with a new, simple option.

I think the only thing preventing that change is that there's not enough interest in moving POSIX forward faster; certainly not like JavaScript.

Another problem are GNU tools. They have many great features but OMG are they a nightmare of inconsistency. BSD extensions tend to be much better thought through, perhaps because GNU tools tend to be lead by a single developer while BSD tools tend to be more team oriented.

So the way forward isn't to replace the organic evolution, it's to layer on processes that refine the proven extensions. And we already have some of those processes in place; we just need to imbue them with more authority, and that starts by not rolling our eyes at standardization and portability.

[ Parent | on HN ]

Re:Benchmarking shell pipelines and the Unix “tools” philosophy by vaingloriole on Tuesday January 07, 2020 @07:14PM (#21986779)

Authority is the problem...not standardization and portability. Everyone is willing and able to tell you the best way to do your work if you use their tools. Straitjacketing implementation in the name of order is a surefire way to dissuade people from using your tools.

[ Parent | on HN ]