This is awesome! I enjoy writing Go and like all the tooling around it. Think shell scripts are hard to read and was already planning to adjust some shell-like-Go-tool this weekend, so this post has perfect timing :-)
Shell-ish scripting in Go with ease
51–60 of 68 posts
Re: Shell-ish scripting in Go with ease
#52Why shouldn't it be as easy to write system administration programs in Go as it is in a typical shell? 1. Shell scripting offers infinite functionality. You can shell script with any program in any language. All it needs to do is take input and produce output. And if the functionality doesn't exist, you can create it on the fly, without having to follow any of the traditional rules of programming. 2. Shell scripting…
>A Sysadmin would take 5 minutes with a shitty language and a shitty tool and get way more done in less time. Most people aren't sysadmins, but occasionally have to do sysadmin-like things. I've been programming with python and go for years. I've never been able to get the "core" command line utilities to really stick in my head. A sysadmin uses them every day, whereas I rarely have to reach for them. On the rare occ…
I completely understand this perspective. But it helps to consider your broader choices.
Let's say you're an "Engineer" engineer, and you deal with units of measurement. You grow up in the US, so you first learn the Imperial system. But so much of the rest of the world uses Metric measurements. Do you find and acquire Imperial versions of every tool, fastener, etc, because it's what you're familiar with? Or do you learn Metric as well, so you can access all of the tools, fasteners, etc found all over the world?
Or take an example from a thousand years ago. Say you're a trader in the Mediterranean and you want to sell your wares. Do you only sell in your local town, where everyone speaks your dialect? Or do you pick up the "Frankish Language", the pidgin language spoken by sailors and other Western Europeans? Learning this mix of Venetian, Catalan, Portuguese, Tamazight, Turkish, Greek, and Arabic will give you extra skills you can use to trade with a vast array of peoples.
POSIX is the closest we have to a 'Mediterranean Basin' for operating systems, and shell scripting is its pidgin language. You don't have to learn it to make a living, but it sure as hell helps.
Re: Shell-ish scripting in Go with ease
#53Earlier quoted context omitted.
This always seemed like the sweet spot for Perl.
500 lines of bash could have been rewritten as 50 lines of dense Perl. Pro: fewer lines of code. Con: even the author would find the Perl script inscrutable after a few weeks.
A more experienced Perl hacker would probably rewrite it as 100 lines of less dense code that people could actually read and comprehend.
I'd probably end up rewriting it as 50 lines of code that used a bunch of pure perl libraries and then use https://p3rl.org/App::FatPacker to bolt the dependencies onto the front for distribution so it was still a single file to install for everybody else.
(there's a lot of perl out there that uses techniques I would switch away from as soon as I got past a one liner in the middle of a pipeline, alas, but it doesn't have to be that way, perl just doesn't stop you blowing both feet off ;)
Re: Shell-ish scripting in Go with ease
#54Earlier quoted context omitted.
One neat thing about Go that makes it superior to a shell script is that it compiles a statically-linked binary. One self-contained file! Or N if you support N platforms. Did I mention that cross-compilation is trivial?
As someone who once inherited a static binary (without debug symbols, gotta save those few bytes) that should have been a shellscript: Please don't. If your logic reasonably fits into a shell script, then put it there. Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.
If a static binary's --help doesn't tell me where the repository lives then I hope the author steps on a lego.
Re: Shell-ish scripting in Go with ease
#55Earlier quoted context omitted.
As someone who once inherited a static binary (without debug symbols, gotta save those few bytes) that should have been a shellscript: Please don't. If your logic reasonably fits into a shell script, then put it there. Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.
If a static binary's --help doesn't tell me where the repository lives then I hope the author steps on a lego.
This is a good idea, will add this to my cli tool :)
Re: Shell-ish scripting in Go with ease
#56I just rewrote a tangled 500 line shell script in go. It was my first time writing a golang project at work, so I'm sure it could have been better. But writing it the naive way, with all the required golang error handling, it ended up taking about 10x more lines of code in golang than the original bash script. It does have a dramatically better UX (largely thanks to spf13's cobra and viper), and is way faster than th…
It depends. For single scripts its too much, but if there are dozen or so scripts with related/similar tasks, there can be common code or pattern to be shared. I have one Go project with ~3kloc and does 20 or so operations. But if were to do just single operation it would still need ~1.5K line of code.
Yeah, the original script I rewrote was doing about 15 different operations depending on the user input/arguments, so I guess it indeed reached the point you're describing where there were a lot of common patterns. It's just that instead of being 15 separate scripts, it was one gigantic one with a lot of conditionals and case statements.
Re: Shell-ish scripting in Go with ease
#57I just rewrote a tangled 500 line shell script in go. It was my first time writing a golang project at work, so I'm sure it could have been better. But writing it the naive way, with all the required golang error handling, it ended up taking about 10x more lines of code in golang than the original bash script. It does have a dramatically better UX (largely thanks to spf13's cobra and viper), and is way faster than th…
Did you do thorough error handling in Bash?
Re: Shell-ish scripting in Go with ease
#58Re: Shell-ish scripting in Go with ease
#59I'm not going to knock the usefulness of the library, but I am going to knock its application. Architecturally, shell scripts should _exclusively_ be for bootstraps, configs, or extremely localized (individual developer) automation. The New York Minute you need non-trivial error-handling/flow-control it's no longer a "shell script" and deserves a proper rewrite in a proper programming language. Ian Malcom's quote fro…
This. And this is why I like the init system on FreeBSD and OpenRC on Alpine Linux, at least on personal computers. Systemd maybe useful on a server, but I only got a few "services" on my PC and I much prefer something that I can easily understand and hack upon.
Truth! Preach!
Re: Shell-ish scripting in Go with ease
#60Why shouldn't it be as easy to write system administration programs in Go as it is in a typical shell? 1. Shell scripting offers infinite functionality. You can shell script with any program in any language. All it needs to do is take input and produce output. And if the functionality doesn't exist, you can create it on the fly, without having to follow any of the traditional rules of programming. 2. Shell scripting…
>A Sysadmin would take 5 minutes with a shitty language and a shitty tool and get way more done in less time. Most people aren't sysadmins, but occasionally have to do sysadmin-like things. I've been programming with python and go for years. I've never been able to get the "core" command line utilities to really stick in my head. A sysadmin uses them every day, whereas I rarely have to reach for them. On the rare occ…
I mean, no one really remembers all the flags. They remember a few common ones, due to using them over and over again.
If you are making a genuine effort to avoid the shell, you won't ever learn these basic flags -- you are holding yourself back. It is like a person complaining about using the stairs -- "On the rare occasion when I _do_ take the stairs, it is excruciating..." -- the problem is not necessarily with the stairs.