7 ms·
Shell-ish scripting in Go with ease
- breadchris 2y agopairing 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 https://github.com/traefik/yaegi
- AzzieElbab 2y agoI hate go-lang with passion, but these two libs are really cool
- throwaway77385 2y agoHow come the hate? That's a pretty strong emotion for something as benign as a programming language.
- wswope 2y agoNot OP, but the usual talking points were covered pretty well in this thread from yesterday: https://news.ycombinator.com/item?id=42884337 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 2y agodependency management in Go is best in class what are you talking about? go mod is that good.
- wswope 2y agoReferring to this thread: https://news.ycombinator.com/item?id=42885476 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 2y agoI 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 2y agoHuh, people are extracting whole bunch of value in Python at expense of society. Should I blame Python or its contributor for it?
- wswope 2y agoI 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.
- radlad 2y agoI 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 2y agoStrongly opinionated languages beget strong opinions on the same, both positive and negative.
- latchkey 2y agoThese sorts of comments always make me wonder what you prefer.
- AzzieElbab 2y agoI make a living with go, scala, python, rust, java, and sometimes ts and Js. I prefer scala and sometimes rust.
- gus_leonel 2y agoSee also go-script: https://til.simonwillison.net/bash/go-script https://til.simonwillison.net/bash/go-script
- LinuxAmbulance 2y agoVery nice, bookmarking this!
- decasia 2y agoI 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 2y agoIt 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.
- decasia 2y agoYeah, 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.
- eschneider 2y agoThis always seemed like the sweet spot for Perl.
- calmbonsai 2y agoI'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 2y agoThis. 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.
- calmbonsai 2y agoTruth! Preach!
- 0xbadcafebee 2y agoWhy 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 2y agoI 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 2y ago>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.
- puika 2y agoIf 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 https://github.com/danicc097/yaegi-script
- tonymet 2y agoa killer feature would be adding a dep tree like make and using goroutines to process the tree concurrently .
- emmelaich 2y agoToo much syntax for a scripting language IMHO.
- desumeku 2y agoThis 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.
- indulona 2y agoright?
- synergy20 2y agofor larger scripts,just use python or lua. otherwise,bash is perfect
- chrooted-user 2y agoThis 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 :-)
- pyuser583 2y agoPlenty of languages have a framework to assist with shell/Bash scripting. Nothing wrong with that. If you look at the Python build-in API, it's pretty terrible. In all fairness, Python strives to work equally well on Windows, Linux, and some other things. Good luck with that. I prefer doing systems scripting in Python over Bash. But writing converting a Bash script to Python without "Pythonizing" it is a bad time.