I write shell one liners all the time[1]. Go is just too verbose for scripting. I use it for larger programs but typically these don't start out as shell scripts. [1] In fact I use find (or zsh's **/*), xargs, grep, sort, uniq, field picking often enough that I wish they were built-in a shell but I haven't figured out a simple syntax for it as yet. > On Jan 3, 2023, at 3:03 PM, ron minnich wrote: > > I apologize for this too long message, but context in this case matters. > > tl;dr: I agree with the Go folks: past about 10 lines, write a program. But not everybody will agree, as I learned with u-root. Many people love shell programming. I never have. > > u-root is a set of Go programs deployed on a couple million data center systems at many companies, including Google. > > u-root originally used a compile-on-demand model: type a command name, if it's not in /ubin, it gets built. This was fast, in early Go, typically 250 ms or so. And, in the early days of Go, the Go toolchain, u-root, and all support source easily fit in a 16M SPI part. > > The original scripting language for u-root was Go. > > There were two commands for this: script and builtin. script would run Go fragments; builtin would take supplied commands and build a custom shell with those built in. Each took 250ms to run. > > script took what we called a 'Go fragment', wrapped it with boiler plate, compiled it, and ran it. > e.g. > script fmt.Printf("hi\n") > would build the program and run that code. > So you could, e.g,, do math: > script fmt.Printf("%d\n", 6*7) > > It could get complex: to see things about interfaces: > script 'ifaces, _ := net.Interfaces() > for _, v := range ifaces { > addrs, _ := v.Addrs() > Printf("%v has %v", v, addrs) > }' > > you'd get: > ip: {1 1500 lo up|loopback} has [127.0.0.1/8 ::1/128] > ip: {5 1500 eth0 fa:42:2c:d4:0e:01 up|broadcast} has [172.17.0.2/16 fe80::f842:2cff:fed4:e01/64] > > The second command was called builtin. It did not work as other shells do: it built a new shell for you. So, you type: > bulitin hi fmt.Printf("hi") there fmt.Printf("there\n") > > builtin would convert the Go fragments to functions callable in the u-root shell, build a private name space (on Linux or Plan 9 anyway), rebuild the shell with those new functions, and at that point: > you type > hi > in the shell, and it types > hi > back. This was built in to your private shell in your private name space. Once you left the shell, it was gone. > Again, this process of creating and starting the new shell always took about 250 ms (in Go 1.2 that is). > > I learned a lesson: people love their shell scripting languages. Nobody wanted to script with Go. It made me sad, but that's how it Go-es. > > ron > p.s. the 'script' command is still available as an experimental u-root command. Source mode is now independent: github.com/u-root/sourcery > > > On Tue, Jan 3, 2023 at 2:35 PM Steffen Nurpmeso > wrote: >> Steve Nickolas wrote in >> >: >> |On Tue, 3 Jan 2023, Dan Cross wrote: >> |> Something I've noticed is that lots of people try to increase >> |> complexity to solve problems, and it rarely occurs to them to >> |> eliminate complexity to solve problems. Sometimes the reasons for this >> |> are good; most of the time they are not. >> |> >> |> - Dan C. >> | >> |I think of the saying: "Perfection is not when there is nothing left to >> |add, but when there is nothing left to remove." >> >> He (Exupéry) was then shot down. >> >> I always seem to response this to that. >> Hmm, openpgp@ietf.org (to which i have almost zero to add >> technically shall someone think that, nor do i want) lastly >> >> |"Perfection is achieved not when there is nothing more to add but when \ >> |there >> |is nothing left to take away" - Antoine de Saint-Exupéry. >> >> He was then shot down. >> >> But yes, he then really went missing. >> >> The topic .. >> I do not miss times where suddenly a shell script breaks because >> ": > FILE" does not work (just recently 'realized from reading code >> of Paul Eggert of GNU/IANA TZ, "hey, > FILE" is of course >> sufficient!"), i fixed it via "printf '' > FILE" by then; whatever >> the reason. May it be bugs or (local) miscompilations, not >> detected due to missing unit tests and a too small user base. >> >> Portable? If i find /usr/xpg4/bin i quickly add it to $PATH for >> the much better awk (but beware of documented double expansion >> issues) and the much much better sh(1). >> Some things just require that, noclobber I/O redirection (set -C) >> for example. (mktemp(1) is still not part of the POSIX standard.) >> >> Besides i miss(ed) the history; the author of bmake (and >> verieexec) just last year asked me why i would use stty for >> a purpose ("(<&1 >/dev/null stty -a) 2>/dev/null") instead of >> simply using "[ -t 1 ]", and indeed, i found that as soon as BSD >> 4.1 and Research V7, but it surprised me. >> Without an oversight of the history and the lack of many systems >> to test, perl(1) was omnipresent and if only for OpenSSL and so >> using it for almost anything seemed save. >> >> To love is not to look at one another: it is to look, >> together, in the same direction. Antoine de Saint-Exupéry. >> >> A happy and healthy new Year 2023 is now overdue. >> Even Giants have to die, but with holding hands it can wait a bit >> longer, i hope. >> I wish that from Germany to all of you, and deliberately beyond >> NATO readership. >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt)