3 ms·

I like me some bash scripting. And I do a lot of it. And I write a good amount of Go. I read the intent of the original package as a bit different than how it’

I like me some bash scripting. And I do a lot of it. And I write a good amount of Go. I read the intent of the original package as a bit different than how it’s presented here; a pain point in using go for systems programming on Posix systems with GNU tooling is interacting with all the other really excellent tools there. There’s an awful lot of cruft to go spawn a shell script in Go without this lib. So, I cannot imagine using this to replace a short-ish bash script, it’s just too heavyweight to add go development into the workflow. But, I can easily imagine using this when I want to do some simple-to-medium-scale pipelined text processing from the middle of a go program.

unfocussed_mike 5y ago
> But, I can easily imagine using this when I want to do some simple-to-medium-scale pipelined text processing from the middle of a go program. Yeah, this is where I see it. I have a cross-platform utility in customer use that replaces a bash script or a .bat file that did a simple job with curl and a database client but was tricky for customers to configure and deploy; I replaced it with an interactively-configurable go command. In the middle of it is the replacement pipe; this library would help here. Might use it in the rewrite.
GordonS 5y ago
Thing is, bash is everywhere (or, at least a POSIX shell is) - for some use cases that matters, because you can't control what is available on the target machine. Even python isn't guaranteed - OK python is fairly ubiquitous, but what version? Shell scripting is far from perfect, and sometimes it does take a while to figure out how to do something that would be easy in another language - but very often, she'll scripting is "good enough".
- oweiler 5y ago
  Bash yes, but commands like sed may or may not support certain flags depending in the platform. https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux https://stackoverflow.com/questions/5694228/sed-in-place-fla...
- jwdunne 5y ago
  This is my feeling too. I’ve written plenty of bash scripts to automate common tasks. Colleagues won’t open them up and extend or maintain them (some developers won’t touch bash). But if they have an easy to use, well documented interface, they will happily use them to be productive. The problem with Python is as you describe. It’s not always guaranteed and if you want everyone’s environment on the same page, you then have to start faffing with virtual envs and/or version managers. This is totally fine on projects written in Python as a whole. But, otherwise, adding complexity to the tool chain is a tough sell to the team. If things get hairy in bash, it’s probably better to extract those parts in the project language and call them from bash. Your build will already be half way there to accommodate this vs introducing a scripting language. Not only that, maintaining those programs involves less context switching. Although mainstream languages blur with enough experience, there is still overhead between juggling idioms, syntax and what not in, say, Python and Go. I’m not perfect: if I’ve been working all day in one language, writing another is like a smack in the face. Sometimes I’ll forget semicolons, or include them. Sometimes I’ll use camel case when really the style in that language is snake case. Not a big deal but it is jarring. There is still context switching with bash but if you use a terminal-based workflow, that does have less of an impact.

unfocussed_mike 5y ago

> But, I can easily imagine using this when I want to do some simple-to-medium-scale pipelined text processing from the middle of a go program. Yeah, this is where I see it. I have a cross-platform utility in customer use that replaces a bash script or a .bat file that did a simple job with curl and a database client but was tricky for customers to configure and deploy; I replaced it with an interactively-configurable go command. In the middle of it is the replacement pipe; this library would help here. Might use it in the rewrite.

GordonS 5y ago

Thing is, bash is everywhere (or, at least a POSIX shell is) - for some use cases that matters, because you can't control what is available on the target machine. Even python isn't guaranteed - OK python is fairly ubiquitous, but what version? Shell scripting is far from perfect, and sometimes it does take a while to figure out how to do something that would be easy in another language - but very often, she'll scripting is "good enough".

oweiler 5y ago
Bash yes, but commands like sed may or may not support certain flags depending in the platform. https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux https://stackoverflow.com/questions/5694228/sed-in-place-fla...
jwdunne 5y ago
This is my feeling too. I’ve written plenty of bash scripts to automate common tasks. Colleagues won’t open them up and extend or maintain them (some developers won’t touch bash). But if they have an easy to use, well documented interface, they will happily use them to be productive. The problem with Python is as you describe. It’s not always guaranteed and if you want everyone’s environment on the same page, you then have to start faffing with virtual envs and/or version managers. This is totally fine on projects written in Python as a whole. But, otherwise, adding complexity to the tool chain is a tough sell to the team. If things get hairy in bash, it’s probably better to extract those parts in the project language and call them from bash. Your build will already be half way there to accommodate this vs introducing a scripting language. Not only that, maintaining those programs involves less context switching. Although mainstream languages blur with enough experience, there is still overhead between juggling idioms, syntax and what not in, say, Python and Go. I’m not perfect: if I’ve been working all day in one language, writing another is like a smack in the face. Sometimes I’ll forget semicolons, or include them. Sometimes I’ll use camel case when really the style in that language is snake case. Not a big deal but it is jarring. There is still context switching with bash but if you use a terminal-based workflow, that does have less of an impact.