[TUHS] Re: A few comments on porting the Bourne shell

[Bakul Shah <bakul@iitbombay.org>]

[-- Attachment #1: Type: text/plain, Size: 6123 bytes --]

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 <rminnich@gmail.com> 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 <http://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 <http://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 <http://github.com/u-root/sourcery>
> 
> 
> On Tue, Jan 3, 2023 at 2:35 PM Steffen Nurpmeso <steffen@sdaoden.eu <mailto:steffen@sdaoden.eu>> wrote:
>> Steve Nickolas wrote in
>>  <alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr <mailto:alpine.DEB.2.21.2301031307001.9988@sd-119843.dedibox.fr>>:
>>  |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 <mailto: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)


[-- Attachment #2: Type: text/html, Size: 7625 bytes --]