Watch on SkipVid platform, alternative to YouTube client watching YouTube videos indirectly, but without ads: https://skipvids.com/?v=-cTsFt-j7rk
I just found this creator who is super excited about the new Bash version. He goes through some aspects of the new changes and features. There is something funny about a guy getting so excited about a new Bash version, that I wanted to share it because of that. :D
Also its nice to see the changes in action and have an explanation from someone who (seemingly) knows what he is doing.
Video (partial) description:
Source Code: github.com/bahamas10/bash-changes
$ whoami Yo what’s up everyone my name’s dave and you suck at programming! Connect with me on my socials below and if you’re reading this you’re legally required to subscribe to my channel.
$ cat source-code The source code for my YSAP series (or related videos) is available for free under the MIT License on GitHub: Source Code → github.com/bahamas10/ysap
Honestly this made me really sad that we’re stuck with this archaic, awful language as a primary way of programmatically interacting with our computers. And I don’t mean to say anybody has done anything wrong here - sh and bash were revolutionary and amazing for their respective times, and maintainers who are keeping bash alive now are heroes who deserve praise. However, many decisions made when sh was originally developed turned out to be footguns, still creating bugs today (despite shellcheck et al).
nushellis somewhat promising but flawed (because it has to be built on the same system interfaces as sh, after all). The most annoying is that there’s no facilities for setting any metadata on data streams (in particular there’s no way to set the format of the data) so everything has to be marshalled manually, which would be OK for a proper programming language but really annoying for a shell. At least it fixes most of the quoting, escaping, interpolation, substition etc awfulness, and allows for manipulating data in a more structured way.I really don’t know if it’s even possible to make a language that would be a good convenient shell and at the same time not prone to bugs which are easily noticeable in other languages. I hope that something like this becomes a reality at some point.
If you want to do a Bash like management and programming, that is not dramatically different but fixes some irritations, then Fish is an alternative. Obviously it will not fix all issues, but there is no paradigm shift in handling streams. nushell is dramatically different and at that point, I would rather use a programming language to do the stuff. Speaking of programming language, there is also Xonsh (basically Python+Bash like combination as a system shell).
All these alternatives have a singular big flaw to me: they are not the standard tools on the system, which defeats the purpose of a system shell to me. In the end, without changing the core system that these shells are built on, I don’t think its possible to make a really well made language that interoperates on system level like a shell does at the moment.
That’s the reason why I got a bit more into Bash to understand some flaws, to understand how to use regexes inside Bash and variable substitutions and a few other concepts that are very useful to know. But man… there are so many traps… like looping over a wildcard for files (such as
for file in *.txt) and if the wildcard does not match, then the loop consists of the wildcard as a literal word as if “*.txt” was a filename. What a stupid idea. There is an option to change that, but that’s the issue. The language is filled with traps and optional options and you have to know all of them.Edit: Added example code why default behavior sucks:
$ for file in *.ABCD; do echo "${file}"; done *.ABCD shopt -s nullglob $ for file in *.ABCD; do echo "${file}"; doneIf you’re trying to avoid a lot of those traps,
shellcheckis pretty cool. I have written my fair share of bash and yet still get caught off-guard by its warnings - and it’s right most of the time!Yes, I use shellcheck in the editor. Its pretty useful. But running (a little bit more complex commands) in the terminal directly won’t help with shellcheck. That’s why I also have a functionality to directly load and edit the current command in the terminal in (Neo)vim and edit and when closing Vim the command gets executed. The benefit doing this is getting checked by shellcheck in the editor and also it makes it easier to one-off complex commands.
Thanks to shellcheck I got in the habbit to always enclose variables in
${var}. And recently learned from a community member that using[[ expr ]]style has basically no downsides against using[ expr ]directly.
