[HN Gopher] Shell-ish scripting in Go with ease
       ___________________________________________________________________
        
       Shell-ish scripting in Go with ease
        
       Author : begoon
       Score  : 112 points
       Date   : 2025-01-31 17:14 UTC (14 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | breadchris wrote:
       | pairing this with yaegi [1] would be interesting. You could
       | having a REPL open doing os operations and when you get the data
       | looking like you want, you select which lines to save to a file.
       | 
       | [1] https://github.com/traefik/yaegi
        
         | AzzieElbab wrote:
         | I hate go-lang with passion, but these two libs are really cool
        
           | throwaway77385 wrote:
           | How come the hate? That's a pretty strong emotion for
           | something as benign as a programming language.
        
             | wswope wrote:
             | Not OP, but the usual talking points were covered pretty
             | well in this thread from yesterday:
             | https://news.ycombinator.com/item?id=42884337
             | 
             | To sum it up, the biggest complaints are error handling,
             | null handling, and dependency management. And y'know, being
             | backed by a company of ghouls hellbent on extracting value
             | for themselves at the expense of society.
        
               | Thaxll wrote:
               | dependency management in Go is best in class what are you
               | talking about? go mod is that good.
        
               | wswope wrote:
               | Referring to this thread:
               | https://news.ycombinator.com/item?id=42885476
               | 
               | I don't personally have a bone to pick with Go mod, save
               | for how the GOPROXY DoS issue was handled.
        
               | wlll wrote:
               | I use Go a lot and I completely disagree. I have also
               | used Ruby a lot and even though I prefer writing Go most
               | of the time (it depends on the task) bundler is far
               | better.
               | 
               | go mod is the second best I've used for sure, but if
               | someone releaed bundler-but-for-go I'd switch to it in a
               | heartbeat.
        
               | geodel wrote:
               | Huh, people are extracting whole bunch of value in Python
               | at _expense of society_. Should I blame Python or its
               | contributor for it?
        
               | wswope wrote:
               | I fundamentally disagree with the assertion that Python
               | operates at the expense of society.
               | 
               | Google is an exploitative monopoly. There's been plenty
               | of ink spilled on the subject to the point that I feel no
               | obligation to repeat it.
               | 
               | While it's true that GVR is currently employed by
               | Microsoft, the ecosystem of Python is far more anarchic
               | and decentralized.
        
               | johnmaguire wrote:
               | I think he was probably making a comment about Python in
               | regards to PyTorch and AI's energy usage.
               | 
               | i.e. Whether a language exists "at the expense of
               | society" probably depends less on who makes the language,
               | and more on what you do with it.
        
             | summarity wrote:
             | Strongly opinionated languages beget strong opinions on the
             | same, both positive and negative.
        
           | latchkey wrote:
           | These sorts of comments always make me wonder what you
           | prefer.
        
         | gus_leonel wrote:
         | See also go-script: https://til.simonwillison.net/bash/go-
         | script
        
       | LinuxAmbulance wrote:
       | Very nice, bookmarking this!
        
       | decasia wrote:
       | I 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 the original, and the
       | codebase is a lot cleaner and more maintainable. So I think it
       | was worthwhile for the users and maintainers.
       | 
       | But still, 10x more lines of code. I like the OP, but I'm still
       | not sure I would reach for golang for short shell scripts.
        
         | geodel wrote:
         | 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.
        
         | eschneider wrote:
         | This always seemed like the sweet spot for Perl.
        
           | sigzero wrote:
           | It is. Very much so.
        
           | sangnoir wrote:
           | 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.
        
         | bqmjjx0kac wrote:
         | 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?
        
           | c0balt wrote:
           | 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.
        
       | calmbonsai wrote:
       | I'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 from Jurassic Park comes to mind:
       | 
       | "Your scientists were so preoccupied with whether or not they
       | could, they didn't stop to think if they should."
        
         | skydhash wrote:
         | 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.
        
       | 0xbadcafebee wrote:
       | Why 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 is a combination of a grammar, operators, a
       | few simple functions, and an extremely loose coupling with
       | generic i/o and logic. I don't know Go well, but it probably
       | doesn't support a similar flexibility. (most languages are very
       | proscriptive about _how_ you can use the language, so you usually
       | can 't make things as easy as they are in a different, more
       | tailored language/interface/paradigm. this is why we have DSLs)
       | 
       | 3. Programmers don't really understand the concept of
       | productivity [outside of programming itself]. A programmer would
       | solve a problem by taking 6 weeks to design a perfect program to
       | do the thing. A Sysadmin would take 5 minutes with a shitty
       | language and a shitty tool and get way more done in less time.
       | And re-writing everything into a Go library would always be
       | slower than shell scripting, because it requires re-implementing
       | what a shell script would just use as-is.
       | 
       | Scripting is duct-taping the wheel rather than reinventing it. If
       | you want to save yourself a whole lot of time and trouble, just
       | use the duct tape.
       | 
       | (also: don't go templates exist? why isn't that used for
       | scripting)
        
         | skydhash wrote:
         | I believe point 2 is the best. Shell scripts are usually
         | software coordinators. Before even starting you already have a
         | collection of software that already does most of the work. The
         | script is just to speed the execution. As an analogy, it's like
         | serving already cooked dishes you ordered. While a programming
         | language is like having the ingredients, and cooking everything
         | yourself. More versatile, but not that easy. And as you say,
         | the first option is better when everyone's hungry.
        
         | graerg wrote:
         | >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
         | occasion when I _do_ have to reach for them, it is excruciating
         | (what was the flag I need for `find` again?). If it were life
         | or death and I had to debug even the simplest sed/awk command,
         | it would be death for me! But this package makes perfect sense
         | to me and really enables me to write this sort of quick and
         | dirty thing in a language I'm familiar with and can confidently
         | maintain.
         | 
         | This isn't for everyone, but there's definitely a population
         | that can get a lot of value out of this.
        
           | wpm wrote:
           | >what was the flag I need for `find` again
           | 
           | This is not on you, `find`'s command line syntax is awful
           | even if you have to use it everyday.
        
             | mbreese wrote:
             | And don't forget GNU vs BSD version differences...
        
               | sgarland wrote:
               | That's why you install gnu-coreutils. Eliminate the
               | difference.
        
             | oguz-ismail wrote:
             | > `find`'s command line syntax is awful
             | 
             | What's awful about it?
        
               | DaSHacka wrote:
               | Everything? It, just like tar, don't follow the
               | convention of many other CLI utilities.
               | 
               | That alone is why I prefer `fd` or plocate for most tasks
               | I previously used find for.
        
               | oguz-ismail wrote:
               | Never heard of plocate but I thought fd a step down from
               | find; it's very limited in functionality, colorful output
               | alone can't justify that.
               | 
               | > [It doesn't] follow the convention of many other CLI
               | utilities.
               | 
               | Because unlike other CLI utilities, find evaluates an
               | expression specified as arguments. Maybe a small DSL like
               | JQ would be better, but how would you embed shell code in
               | it? Meh.
        
               | DaSHacka wrote:
               | Find has its uses, I use it frequently to correct
               | improper unix file permissions and owners and when I need
               | to execute a command on a list of files.
               | 
               | However for the vast majority of queries, I'm only
               | looking for something based on the filename, and that's
               | where having sane regex and standard argument structure
               | (like fd has) is great.
        
               | oguz-ismail wrote:
               | > for the vast majority of queries, I'm only looking for
               | something based on the filename
               | 
               | I'd manage with find|grep but yes, nothing wrong with
               | wanting something more compact.
               | 
               | > sane regex
               | 
               | For me that's POSIX ERE, I don't know which flavor fd
               | uses.
        
           | Zamiel_Snawley wrote:
           | LLMs are pretty good at using the standard utilities.
           | 
           | That, combined with reading the man pages if it doesn't work
           | first try has been really effective for me.
        
         | stonewhite wrote:
         | Good points. 3rd one reminds me of the Knuth vs McIllroy story
         | about 10+ page pascal vs 6 bash pipes[1]
         | 
         | [1]: https://leancrew.com/all-this/2011/12/more-shell-less-egg/
        
         | jayd16 wrote:
         | You can run a shell command from a language you like so they're
         | just as flexible. Go and many other languages have Exec (or
         | equivalent).
         | 
         | The major reason shell scripting is nice is because its
         | portable with a copy/paste and HelloWorld.sh doesn't need a
         | compiler or a VM or even any preceding incantation to run.
         | 
         | As much as I hate that this is where my hopes are, I do hope
         | that Powershell gets to a point where you can write single C#
         | files and run them.
        
           | teleforce wrote:
           | D language rdmd wrapper allows to compile-and-execute
           | directly [1].
           | 
           | Together with intuitive function calling facility using
           | Uniform Function Call Syntax or UFCS you can easily has
           | natively compiled scripting environment [2],[3].
           | 
           | [1] Pragmatic D Tutorial:
           | 
           | https://qznc.github.io/d-tut/hello.html
           | 
           | [2] Why I use the D programming language for scripting (2021)
           | (50 comments):
           | 
           | https://news.ycombinator.com/item?id=36928485
           | 
           | [3] Uniform Function Call Syntax:
           | 
           | https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
        
             | Zamiel_Snawley wrote:
             | You can write executable "scripts" in C by JIT compiling
             | them with the shebang.
             | 
             | Tcc has the `-run` flag for easily doing this with a
             | normal-ish shebang.
             | 
             | With a nasty polyglot preamble of C and bash at the top of
             | your file, you can do it with any compiler.
        
       | puika wrote:
       | If anyone wants to experiment with this lib + yaegi interpreter I
       | put up a trivial example at [1]. Composing scripts with LSP
       | support and such might be doable with a proper abstraction, in
       | the example a main package with a main function is required.
       | Interpreting might break some functionality for `script` so
       | perhaps rerunning their test suite with yaegi is a good idea if
       | you get serious about this.
       | 
       | 1. https://github.com/danicc097/yaegi-script
        
       | tonymet wrote:
       | a killer feature would be adding a dep tree like make and using
       | goroutines to process the tree concurrently .
        
       | emmelaich wrote:
       | Too much syntax for a scripting language IMHO.
        
       | desumeku wrote:
       | This site is horrible. Every comment here is trying their hardest
       | to systematically dismantle this library out of existence through
       | the use of nihilistic mind-games about what "shell scripting"
       | "really" "is". All because they don't like a programming language
       | that much.
        
       | synergy20 wrote:
       | for larger scripts,just use python or lua. otherwise,bash is
       | perfect
        
       ___________________________________________________________________
       (page generated 2025-02-01 08:01 UTC)