shells are a tool to get things done. uniformity does help with this, as do the available resources. think "how do i do <x> in bash" vs "how do i do <x> in ksh" on stack overflow.
fish is great for my productivity, but the fact that it isn't quite bash compatible remains a constant friction/pain point. i'm glad it exists, but find it difficult to recommend in many cases.
another example of this is how dash/ash is the default shell for /bin/sh on Ubuntu (and other Linux distros). for day-to-day work, very few people care that it isn't bourne shell.
still, good to see them being put out there, even if the "selling points" of those shells in the PR don't resonate with me personally. if i'm going to the trouble of modifying my shell to be more productive, maybe even going so far as to try a different shell, being the defaults on some systems doesn't seem like a big win.
Yeah good point. Bash and/or another shell is likely to be easily installable on whatever system you're on, you have no obligation to use the default shell.
I guess my main point with the PR was just not to ignore history and point out that both ksh and tcsh are both actively used and maintained. Ok they're not as popular of course but then again BSD isn't as popular as Linux but they are still relevant and active. In a repo that is years old at this point, has 16,000+ stars and would be considered a comprehensive guide on anything shell it's a very basic omission.
As for uniformity, in terms of scripts, for 99% of use cases I write them in POSIX shell, for portability too. Anything that falls out of this I'd potentially reach for a Bash or Ksh feature but as a rule of thumb, if what I'm trying to do calls for an array, which bash can provide then that's the point I think, that you should be moving onto a more featureful language.
2 comments
[ 2.3 ms ] story [ 15.2 ms ] threadfish is great for my productivity, but the fact that it isn't quite bash compatible remains a constant friction/pain point. i'm glad it exists, but find it difficult to recommend in many cases.
another example of this is how dash/ash is the default shell for /bin/sh on Ubuntu (and other Linux distros). for day-to-day work, very few people care that it isn't bourne shell.
still, good to see them being put out there, even if the "selling points" of those shells in the PR don't resonate with me personally. if i'm going to the trouble of modifying my shell to be more productive, maybe even going so far as to try a different shell, being the defaults on some systems doesn't seem like a big win.
I guess my main point with the PR was just not to ignore history and point out that both ksh and tcsh are both actively used and maintained. Ok they're not as popular of course but then again BSD isn't as popular as Linux but they are still relevant and active. In a repo that is years old at this point, has 16,000+ stars and would be considered a comprehensive guide on anything shell it's a very basic omission.
As for uniformity, in terms of scripts, for 99% of use cases I write them in POSIX shell, for portability too. Anything that falls out of this I'd potentially reach for a Bash or Ksh feature but as a rule of thumb, if what I'm trying to do calls for an array, which bash can provide then that's the point I think, that you should be moving onto a more featureful language.