3 ms·
I am with the author on the general point. But I think it ignores the fact discussing how things were in the '60s when the commands were written just for people
by tclancy 7y ago
I am with the author on the general point. But I think it ignores the fact discussing how things were in the '60s when the commands were written just for people ignores a fundamental change. To wit:
>the added options are convenience flags: setting the permissions of the new directory and making parent directories if they don't exist.
Obviously completely unnecessary for normal users, but those have to exist for automated processes. The "problem" is caused in part by the success of Unix, that now computers are using computers.
- oefrha 7y agoIf you believe mkdir -p is completely unnecessary for normal users and only exists for scripting, you probably want to think about how it might fit into your workflow again. In fact, my mkdir is simply aliased to mkdir -p, and I have a self evidently-named wrapper function called mkcd which I use even more often than mkdir.
- AnIdiotOnTheNet 7y agoSince one can alias commands to functions, that does suggest that in fact mkdir -p is actually unnecessary.
- tclancy 7y agoI immediately second-guessed my use of "Obviously completely"-- what I meant was "We can get by without it" whereas a standalone script cannot.
- oefrha 7y agoWell a script can do path parsing too, it’s just rather painful. Similar (actually more complex) real world task that does get implemented in POSIX sh: realpath(1) replacement, when it doesn’t exist.
- jmmcd 7y agoWait, what does mkcd do?
- gumby 7y agoI think that’s backwards: it’s a convenience function for interactive use. Sure it’s convenient for writing scripts too but a script could just as well include some boilerplate for the functionality if required and it if not. This is the argument between CISC and RISC.
- jcranmer 7y agoBut he doesn't ignore it... the last paragraph says: > To be clear, I'm not saying that I or anyone else could have done better with the knowledge available in the 70s in terms of making a system that was practically useful at the time that would be elegant today. It's easy to look back and find issues with the benefit of hindsight. What I disagree with are comments from Unix mavens speaking today, with comments like McIlroy's, which imply that we just forgot or don't understand the value of simplicity, or Ken Thompson saying that C is as safe a language as any and if we don't want bugs we should just write bug-free code. These kinds of comments imply that there's not much to learn from hindsight, we were building things as well as anyone could build things in the 70s, all we have to do is go back to building systems like the original Unix mavens and all will be well. I respectfully disagree. In other words, the real problem isn't that modern software is getting more complex (as there is a good reason for it); the problem is that we're insisting on using an environment that is not up to the task of dealing with modern complexity. For an example of how insane this world is: consider putting your source trees in a location that contains a space in its name. How many build systems are going to completely and utterly fail to build your code? And... why should we tolerate this situation?