The `hostname` part is wrong, it needs to be quoted. If we want to talk about actually hating the shell, just use this one weird trick where merely comparing an integer to untrusted input constitutes an RCE vuln:
$ X='a[$(touch pwned1)]'; [[ $X -eq 0 ]]
Oddly, quoting doesn't fix it:
$ X='a[$(touch pwned2)]'; [[ "$X" -eq 0 ]]
Shells are not good for what they do. Literally half of any *sh script is just reading somedata.somefield but implemented with (poorly defined and poorly written) regex to compensate for some genius UN*X utility's output which is totally not meant to be parsed but we're still gonna parse it anyway because we didn't have the most simple foresight of how data will be delivered to other programs. Then there's stuff like working around crap to be able to do something like -c -arbitrary_input, such as -- which may or may not exist or be applicable. It's hilariously BAD. They are not fast to use as opposed to general purpose languages, because you are just adding a bunch of bugs to your system each time you take any RAD affordance it purports to offer.
*sh fits into the category of C for extremely poorly designed languages. In this case, instead of having bugs like duff's device and UB flying all over the place even where there's no rationale for it, we have a similarly poorly defined language where parts of the language itself may or may not exist (including the minimal set of commands you need in practice to get anything done, despite them being not part of the shell) depending on which implementation you use, and POSIX has to step in and try to post-hoc tell people what's portable and steer future direction, and you have random cargo cult like x -eq x$var (or whatever that was, yeah I've spent a week of my life learning *sh and hope to never spend another minute more).
The example where he shows editing a command is hilariously bad. It requires knowing some obscure shortcut in a bizarre unreadable manual, knowing how escape sequences work (if you want to change the key binding), having $EDITOR set. Basically you need a few years of UN*X indoctrination to understand all these mechanics, and you will still get them wrong, for example how $PS1 is always wrong (no not just me, in the big distros they are buggy). And as the command grows your shell is spammed and you quickly lose everything off scrollback, as opposed to simply assigning a name to the code you're working on or having an abbreviated form be displayed. Whatever your $EDITOR is set to will also be a thing that takes a year to become efficient in. Formatting with each bar on one line is also just another work around for text based languages. This is why all REPLs (which are just that: a quick hack) suck, despite being the fundamental core of an OS. It's just a poor approximation of what can much more easily and efficiently be done with a raster scan monitor as opposed to a terminal from the 70s.
Using the shell doesn't make you a hacker. It makes you a quack. 10 years ago I remember trying to do stuff on a UN*X system with only terminal, that involved merely printing some untrusted input, and I piped it through a small program I made to strip out anything outside [0x20, 0x7F]. 10 years later I had time to audit it and found out I was indeed correct. You literally can't do ANYTHING in the shell and be secure. It's a nightmare. What's RVM? I'm gonna go audit that. Zsh actually seems to be a bunch of security footguns. Even their security features are broken (such as bracketed paste, which is always broken anyway).
There is not even anything valuable in the shell that makes it worth preserving. It's entire job is to be compatible with a bunch of bad decisions made 50 years ago (yes, some of then were justified due to the paradigm being different back then). All your doing by using *sh is trying to be compatible with all these garbage tools. All these utilities like grep sed awk are moot (on top of being microcosms of the same issues of *sh) because you shouldn't be parsing things anyway. Imagine using this rube golberg shit in your mission critical embedded devices like vehicles.
$ X='a[$(touch pwned1)]'; [[ $X -eq 0 ]]
Oddly, quoting doesn't fix it:
$ X='a[$(touch pwned2)]'; [[ "$X" -eq 0 ]]
Shells are not good for what they do. Literally half of any *sh script is just reading somedata.somefield but implemented with (poorly defined and poorly written) regex to compensate for some genius UN*X utility's output which is totally not meant to be parsed but we're still gonna parse it anyway because we didn't have the most simple foresight of how data will be delivered to other programs. Then there's stuff like working around crap to be able to do something like -c -arbitrary_input, such as -- which may or may not exist or be applicable. It's hilariously BAD. They are not fast to use as opposed to general purpose languages, because you are just adding a bunch of bugs to your system each time you take any RAD affordance it purports to offer.
*sh fits into the category of C for extremely poorly designed languages. In this case, instead of having bugs like duff's device and UB flying all over the place even where there's no rationale for it, we have a similarly poorly defined language where parts of the language itself may or may not exist (including the minimal set of commands you need in practice to get anything done, despite them being not part of the shell) depending on which implementation you use, and POSIX has to step in and try to post-hoc tell people what's portable and steer future direction, and you have random cargo cult like x -eq x$var (or whatever that was, yeah I've spent a week of my life learning *sh and hope to never spend another minute more).
The example where he shows editing a command is hilariously bad. It requires knowing some obscure shortcut in a bizarre unreadable manual, knowing how escape sequences work (if you want to change the key binding), having $EDITOR set. Basically you need a few years of UN*X indoctrination to understand all these mechanics, and you will still get them wrong, for example how $PS1 is always wrong (no not just me, in the big distros they are buggy). And as the command grows your shell is spammed and you quickly lose everything off scrollback, as opposed to simply assigning a name to the code you're working on or having an abbreviated form be displayed. Whatever your $EDITOR is set to will also be a thing that takes a year to become efficient in. Formatting with each bar on one line is also just another work around for text based languages. This is why all REPLs (which are just that: a quick hack) suck, despite being the fundamental core of an OS. It's just a poor approximation of what can much more easily and efficiently be done with a raster scan monitor as opposed to a terminal from the 70s.
Using the shell doesn't make you a hacker. It makes you a quack. 10 years ago I remember trying to do stuff on a UN*X system with only terminal, that involved merely printing some untrusted input, and I piped it through a small program I made to strip out anything outside [0x20, 0x7F]. 10 years later I had time to audit it and found out I was indeed correct. You literally can't do ANYTHING in the shell and be secure. It's a nightmare. What's RVM? I'm gonna go audit that. Zsh actually seems to be a bunch of security footguns. Even their security features are broken (such as bracketed paste, which is always broken anyway).
There is not even anything valuable in the shell that makes it worth preserving. It's entire job is to be compatible with a bunch of bad decisions made 50 years ago (yes, some of then were justified due to the paradigm being different back then). All your doing by using *sh is trying to be compatible with all these garbage tools. All these utilities like grep sed awk are moot (on top of being microcosms of the same issues of *sh) because you shouldn't be parsing things anyway. Imagine using this rube golberg shit in your mission critical embedded devices like vehicles.