4 ms·

I'm also a bash expert and I agree! I wrote 75 lines of bash to do failure-resistant streaming parallel computation on heterogeneous distributed systems. "para

I'm also a bash expert and I agree! I wrote 75 lines of bash to do failure-resistant streaming parallel computation on heterogeneous distributed systems. "parallel" was very close to doing what I want, but it wasn't particularly hard to do it myself without it. I fire it up, peg every core on as many spot instances as AWS will give me, then shut them all down. I regularly pass data structures through pipes, and "jq" does everything I have needed so far. The tools can always get a bit better, but I don't need my duct tape to be any smarter, KTHX.

arpa 5y ago
what makes one a bash expert? genuinely curious if i could call myself one.
- deleted 5y ago
  [deleted]
- Bluecobra 5y ago
  What makes me an expert is the amount of computer books I have near my desk. Sort of like how the enchantment table works in Minecraft. I am also a bash expert because I own an O’Reilly book on the subject I bought at a Borders 20 years ago at retail price. :)
  - arpa 5y ago
    I am a bash expert as well then, and probably the only person insane enough to have a web framework, complete with http server written in bash.
    - LilBytes 5y ago
      I'd say you were both masochistic and way beyond just being an expert in that case. Bash Technical Fellow?
- thanatos519 5y ago
  10 years ago my colleagues were astounded by my airtight bash scripts which formed the backbone of our deployment pipeline. I've come a long way since then, and I still learn new things about it regularly, so I guess I'm a bash expert.
laumars 5y ago
I’m also a bash expert but I disagree with your point. Bash was good enough when being a sysadmin meant your structured data was largely just flat lists of plain text. However the industry moved away from that model years ago. And these days it’s more pronounced than ever with myself spending more time in YAML, JSON and tables thanks to modern DevOps tooling than I have done in the 2 decades of experience I had prior. Sure, jq is amazing. But if I’m having to reach for jq in nearly every pipeline then one has to question why the shell can’t just understand JSON natively itself. And why should I have to learn a different tool with their own formatting language for working with YAML, CSV, XML, S-expressions and so on. Why can’t I use the same shell primitives regardless of the underlying data format is? This is why I switched away from bash. I’m enough of an expert in bash to use it for DevOps everyday but I’m also pragmatic enough to realise that other shells actually do offer quality of life improvements. This doesn’t mean those shells have to be fully fledged programming languages - I’m really not suggesting that we should be using shell scripting for anything complicated. The problem is the stuff that isn’t complicated has evolved to become complicated in bash because the nature of our work has shifted away from what bash did well. But each to their own. I wouldn’t want to impose my workflow on others anymore than I’d want others to lecture me about theirs. I just wanted to offer a counterpoint from someone who is also a seasoned sysadmin (and more recently “DevOps”).
- thanatos519 5y ago
  I see your point, and you're right - it is a matter of personal taste. That's just where I draw the line as to what the shell should understand. I'm mostly in K8s these days where JSON and YAML are interchangeable so I just need jq (or yq, which is just a jq wrapper). I'm curious, though, what other shells offer 'quality of life improvements' ... and can I convince my colleagues to install it everywhere?
  - laumars 5y ago
    > I'm curious, though, what other shells offer 'quality of life improvements' To be honest most alt of them do. Bash has enough footguns to incapacitate a small army. Seasoned users like ourselves know how to mitigate them but using a shell that doesn’t require a conscious effort to support spaces in file names and other really basic things is one less piece of mental overhead I need to consider when working. > and can I convince my colleagues to install it everywhere? I’m not sure what you mean here. Are you trying to convince your colleagues to switch so you all use the same shell or saying you still spend a lot of time in remote SSH sessions? Either way, it sounds like you’re probably best sticking with Bash if those are your requirements. My remote workflow is largely API driven (serverless) and the few times I do need to SSH into a remote instance it’s usually just to perform basic tasks. The real meat of my console work is done locally these days.

arpa 5y ago

what makes one a bash expert? genuinely curious if i could call myself one.

deleted 5y ago
[deleted]
Bluecobra 5y ago
What makes me an expert is the amount of computer books I have near my desk. Sort of like how the enchantment table works in Minecraft. I am also a bash expert because I own an O’Reilly book on the subject I bought at a Borders 20 years ago at retail price. :)
- arpa 5y ago
  I am a bash expert as well then, and probably the only person insane enough to have a web framework, complete with http server written in bash.
  - LilBytes 5y ago
    I'd say you were both masochistic and way beyond just being an expert in that case. Bash Technical Fellow?
thanatos519 5y ago
10 years ago my colleagues were astounded by my airtight bash scripts which formed the backbone of our deployment pipeline. I've come a long way since then, and I still learn new things about it regularly, so I guess I'm a bash expert.

laumars 5y ago

I’m also a bash expert but I disagree with your point. Bash was good enough when being a sysadmin meant your structured data was largely just flat lists of plain text. However the industry moved away from that model years ago. And these days it’s more pronounced than ever with myself spending more time in YAML, JSON and tables thanks to modern DevOps tooling than I have done in the 2 decades of experience I had prior. Sure, jq is amazing. But if I’m having to reach for jq in nearly every pipeline then one has to question why the shell can’t just understand JSON natively itself. And why should I have to learn a different tool with their own formatting language for working with YAML, CSV, XML, S-expressions and so on. Why can’t I use the same shell primitives regardless of the underlying data format is? This is why I switched away from bash. I’m enough of an expert in bash to use it for DevOps everyday but I’m also pragmatic enough to realise that other shells actually do offer quality of life improvements. This doesn’t mean those shells have to be fully fledged programming languages - I’m really not suggesting that we should be using shell scripting for anything complicated. The problem is the stuff that isn’t complicated has evolved to become complicated in bash because the nature of our work has shifted away from what bash did well. But each to their own. I wouldn’t want to impose my workflow on others anymore than I’d want others to lecture me about theirs. I just wanted to offer a counterpoint from someone who is also a seasoned sysadmin (and more recently “DevOps”).

thanatos519 5y ago
I see your point, and you're right - it is a matter of personal taste. That's just where I draw the line as to what the shell should understand. I'm mostly in K8s these days where JSON and YAML are interchangeable so I just need jq (or yq, which is just a jq wrapper). I'm curious, though, what other shells offer 'quality of life improvements' ... and can I convince my colleagues to install it everywhere?
- laumars 5y ago
  > I'm curious, though, what other shells offer 'quality of life improvements' To be honest most alt of them do. Bash has enough footguns to incapacitate a small army. Seasoned users like ourselves know how to mitigate them but using a shell that doesn’t require a conscious effort to support spaces in file names and other really basic things is one less piece of mental overhead I need to consider when working. > and can I convince my colleagues to install it everywhere? I’m not sure what you mean here. Are you trying to convince your colleagues to switch so you all use the same shell or saying you still spend a lot of time in remote SSH sessions? Either way, it sounds like you’re probably best sticking with Bash if those are your requirements. My remote workflow is largely API driven (serverless) and the few times I do need to SSH into a remote instance it’s usually just to perform basic tasks. The real meat of my console work is done locally these days.