[TUHS] sh and goto

[TUHS] sh and goto

[srbourne]

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

    Message: 4

    Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST)
    From:jason-tuhs@shalott.net
    To:tuhs@minnie.tuhs.org
    Subject: Re: [TUHS] The UNIX Command Language (1976)
    Message-ID:
    	<alpine.LRH.2.23.453.2011301946410.14253@waffle.shalott.net>
    Content-Type: text/plain; charset="utf-8"; Format="flowed"


>     "The UNIX Command Language is the first-ever paper published on the Unix
>     shell. It was written by Ken Thompson in 1976."
>
>     https://github.com/susam/tucl

    Thanks for that.

    This reminded me that the Thompson shell used goto for flow control, which
    I had forgotten.

    Bourne commented on the omission of goto from the Bourne shell, "I
    eliminated goto in favour of flow control primitives like if and for.
    This was also considered rather radical departure from the existing
    practice."

    Was this decision contentious at all?  Was there a specific reason for
    goto's exclusion in the Bourne shell?


    Thanks.


       -Jason

At the time it may have raised a few eyebrows but I don't recall much discussion about it then.  My email tracks at the time don't mention it.
Doug McIlroy or Steve Johnson (or Ken) on this forum might recall differently.  At the time scripts were not that complicated and so error recovery to a far off place in the script was not common.  As an aside I did persuade Dennis to add "setjmp" and "longjmp" so the shell code itself could recover from some kinds of script errors.
So I did not have a "religious" aversion to "goto" at the time.

Steve


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

Re: [TUHS] sh and goto

[Ken Thompson]

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

it was the right thing to do.
wish i had thought of it.
i was too busy saving bytes.


On Tue, Dec 15, 2020 at 8:03 AM srbourne <srbourne@gmail.com> wrote:

> Message: 4
>
> Date: Mon, 30 Nov 2020 19:59:18 -0800 (PST)
> From: jason-tuhs@shalott.net
> To: tuhs@minnie.tuhs.org
> Subject: Re: [TUHS] The UNIX Command Language (1976)
> Message-ID:
> 	<alpine.LRH.2.23.453.2011301946410.14253@waffle.shalott.net> <alpine.LRH.2.23.453.2011301946410.14253@waffle.shalott.net>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>
>
> "The UNIX Command Language is the first-ever paper published on the Unix
> shell. It was written by Ken Thompson in 1976."
> https://github.com/susam/tucl
>
> Thanks for that.
>
> This reminded me that the Thompson shell used goto for flow control, which
> I had forgotten.
>
> Bourne commented on the omission of goto from the Bourne shell, "I
> eliminated goto in favour of flow control primitives like if and for.
> This was also considered rather radical departure from the existing
> practice."
>
> Was this decision contentious at all?  Was there a specific reason for
> goto's exclusion in the Bourne shell?
>
>
> Thanks.
>
>
>   -Jason
>
>
> At the time it may have raised a few eyebrows but I don't recall much discussion about it then.  My email tracks at the time don't mention it.
> Doug McIlroy or Steve Johnson (or Ken) on this forum might recall differently.  At the time scripts were not that complicated and so error recovery to a far off place in the script was not common.  As an aside I did persuade Dennis to add "setjmp" and "longjmp" so the shell code itself could recover from some kinds of script errors.
> So I did not have a "religious" aversion to "goto" at the time.
>
> Steve
>
>

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

Re: [TUHS] sh and goto

[George Michaelson]

HN has a story about a safe bash script template. Putting to one side
the oxymoronic qualities of the sentence, the thing which stands out
is the use of trap to a function on SIG<x> -Which we all need, but
often don't do. Thumping ^C repeatedly when things go unexpectedly
wrong, is a fact of life. What do you want your script to do?

Coding for the unexpected is just hard. Going into a script (or
program) pre-thinking that you have to 'expect the unexpected' breaks
the design imperative of planning for success. IF-THEN-ELSE doesn't
always cope well with mental models of "do A,B,C but if Z happens get
2 dozen milk" (which leads to the joke about programmers shopping
instructions with an IF clause in it)

The trap thing in shell always confused me. What state am I "in" when
I wind up in that trap? do variables exist (no: IIRC the var=value
flow in a shellscript is lazy so the un-instantiated x=y inside an if
expression you don't know was reached or not MAY not exist)  has
sub-job completed, (can trap pre-empt a wait statement? of course it
can! what does it mean for children reaping... you do know the PID
right?)

None of this is rocket surgery. It goes to lawyer-like legalistic "one
side of one cow in one field is black" reasoning -which for a program
is probably not a bad thing, but it isn't very human(e) thinking for
some people.

Then enters ^T (the TOPS-10 inherited "what state am I in, in terms of
CPU time and I/O") which somebody *else* is dealing with: the thing
which called your shell instance..

trap is a setjmp/longjmp type outcome. You pop up in a call you didn't
exactly "plan" for (well you did: you wrote it. But you don't know the
entry state which led you there, unlike normal program flow) -well, it
is.. because you get there. But you aren't going back to your normal
logic flow anytime soon in any shellscript I saw.

Re: [TUHS] sh and goto

[Richard Salz]

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

> trap is a setjmp/longjmp type outcome. You pop up in a call you didn't
> exactly "plan" for (well you did: you wrote it. But you don't know the
> entry state which led you there, unlike normal program flow) -well, it
> is.. because you get there.


I once won a Usenix contest for using /bin/sh to test your reflexes.

trap "ls | wc ; exit 0" 0 1 2 3 15
ls * | wc -l
echo "Type ^C; see how close you can make your number match"
rm -rf * | wc -l
kill -1 $$ # For those without "trap 0"

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

Re: [TUHS] sh and goto

[George Michaelson]

Great solution. Not entirely "side effect free.."

On Wed, Dec 16, 2020 at 2:30 PM Richard Salz <rich.salz@gmail.com> wrote:
>
>
>> trap is a setjmp/longjmp type outcome. You pop up in a call you didn't
>> exactly "plan" for (well you did: you wrote it. But you don't know the
>> entry state which led you there, unlike normal program flow) -well, it
>> is.. because you get there.
>
>
> I once won a Usenix contest for using /bin/sh to test your reflexes.
>
> trap "ls | wc ; exit 0" 0 1 2 3 15
> ls * | wc -l
> echo "Type ^C; see how close you can make your number match"
> rm -rf * | wc -l
> kill -1 $$ # For those without "trap 0"
>

[TUHS] sh and goto

[M Douglas McIlroy]

> Bourne commented on the omission of goto from the Bourne shell
...
> Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell?

I don't believe I ever used a shell goto, because I knew
how it worked--maybe even spinning a tape drive, not too
different from running a loop on the IBM CPC. There you
stood in front of the program "read head" (a card reader),
grabbed the "used" cards at the bottom and put them back
in the top feed. Voila, a program loop. The shell goto
differed in that it  returned to the beginning by running the
tape backward rather than going around a physically
looped path. And you didn't have to spin the tape by hand.

It also reminds me of George Stibitz's patent on the goto.
The idea there was to stop reading this tape and read
that one instead. The system library was a bank of
tape readers with programs at the ready on tape loops .
(This was in the late 1940s. I saw the machine but never
used it. I did have hands-on experience with CPCcards.)

Doug