The Shell Hater's Handbook (2010) [video](youtube.com)
youtube.com
The Shell Hater's Handbook (2010) [video]
https://www.youtube.com/watch?v=olH-9b3VJfs
9 comments
Related:
The Shell Hater's Handbook (2010) [video] - https://news.ycombinator.com/item?id=14010484 - April 2017 (45 comments)
The Shell Haters Handbook - https://news.ycombinator.com/item?id=1705278 - Sept 2010 (31 comments)
The Shell Hater's Handbook (2010) [video] - https://news.ycombinator.com/item?id=14010484 - April 2017 (45 comments)
The Shell Haters Handbook - https://news.ycombinator.com/item?id=1705278 - Sept 2010 (31 comments)
Anybody knows what Ryan Tomayko is up to now? His Twitter account doesn't exist anymore (https://twitter.com/rtomayko) and his Github (https://github.com/rtomayko) shows 0 activity
It's a delightful talk.
So many things are covered in there that caused me to grind my teeth when I inherited dense bash scripts, thousands of lines long, that someone had really gone to town with back in the day. So fugly, yet somehow "it works".
So many things are covered in there that caused me to grind my teeth when I inherited dense bash scripts, thousands of lines long, that someone had really gone to town with back in the day. So fugly, yet somehow "it works".
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.
So, what are unix/linux sysadmin supposed to do ? Move everything to WSL and learn Powershell ? Wasn't there a Powershell for linux project at some point ?
This is probably something I'd find interesting and enjoyable but: the video doesn't load (for whatever reason), the slides have no "Next" button (for whatever reason), and there is no plain text transcript... so I guess I'll have to skip it.
Seriously, when you prepare a long talk, surely you write the script beforehand, right? Then upload it (in a text format), please! Also, there is nothing wrong with PDF slides: those don't look too great, but at least they don't usually have problem with scrolling.
Seriously, when you prepare a long talk, surely you write the script beforehand, right? Then upload it (in a text format), please! Also, there is nothing wrong with PDF slides: those don't look too great, but at least they don't usually have problem with scrolling.
from looking at view-source:https://shellhaters.org/deck/ it seems they hand-rolled their own navigation -- try pressing "?" to bring up the (ahem) navigation controls
based on the topic of the talk, your experience, and the fact they hand rolled something present in browsers since the 90s -- I can't tell if it's satire or what
based on the topic of the talk, your experience, and the fact they hand rolled something present in browsers since the 90s -- I can't tell if it's satire or what
which part is already present in browsers?
navigation between pages, or if one wishes super hard to be SPA JS-y, `addEventListener` and `history.pushState`, although that wasn't what I meant when I made reference to the 90s -- the PNGs used by the slide deck exist as resources on the server, so one does not need JS to view them, even in an _o_rdered _l_ist of elements of <img>
I'm not being "you kids get off my lawn" as much as I don't follow how rolling your own opaque and obviously user hostile custom navigation framework-whatever enhances the message the author is trying to convey about how "shell is hard"
I'm not being "you kids get off my lawn" as much as I don't follow how rolling your own opaque and obviously user hostile custom navigation framework-whatever enhances the message the author is trying to convey about how "shell is hard"
This is probably because shellhaters.org is written in bash.
I had to use the left arrow key and "rewind" it. That brought me back to that same first slide, but now I can move forward through it. No clue why.
I figured out the same, but if I try to right arrow through a slide too quickly (less than 5 to 10 seconds) it seems to ignore it
The server hosting the video file itself is returning a 500 response at the moment.
There are 404s for js files and javascript errors in the console when I hit right arrow, but after a while (a few tries) I'm able to start using left and right arrows (inconsistently) in the slide deck. Looks like they require the speaking to mean much though.
Oh hey, here's the talk to YouTube (2010) https://www.youtube.com/watch?v=olH-9b3VJfs
Oh hey, here's the talk to YouTube (2010) https://www.youtube.com/watch?v=olH-9b3VJfs
The talk is available on YouTube: https://www.youtube.com/watch?v=olH-9b3VJfs
Can we replace this post with the YT video?
OK, we've changed to that from https://shellhaters.org/talk, which seems not to be working for some. Thanks!
This is not a handbook. It's a video that doesn't load with slides in some kind of hard-to-navigate browser-only format.
> This is not a handbook.
The title is an attempt to link the video to "The UNIX-HATERS Handbook" which was eventually printed as a handbook.
https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook
The title is an attempt to link the video to "The UNIX-HATERS Handbook" which was eventually printed as a handbook.
https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook
I understood the reference and was expecting something like that book. (Though TUHH also considers the shell.) I was disappointed this wasn't the case.
Please enjoy my Mona Pizza.
No, it is a pizza, not a painting. The title is an attempt to link the pizza to a much more famous painting, because that apparently works well enough to get on HN.
No, it is a pizza, not a painting. The title is an attempt to link the pizza to a much more famous painting, because that apparently works well enough to get on HN.
> because that apparently works well enough to get on HN
If it was upvoted by HN users, then it "works well enough" for HN.
Also, this practice is very common. Consider all of the "X considered harmful" media.
If it was upvoted by HN users, then it "works well enough" for HN.
Also, this practice is very common. Consider all of the "X considered harmful" media.
This website is pretty darn broken. Anyone know who is in charge of it?
URL changed from https://shellhaters.org/talk now.
I see a lot of people complaining about shell and wanting to replace all shell uses with other languages like python or ruby. Yet when you try to do that, you often end up with long sequences of code that shell can do in a few much clearer lines. Invoking a command is trivial in shell, that is what it is optimized to do.
Shell is good for some things, and terrible for others... just like any other programming language.