Make it POSIX

[hlangeveld]

Two major updates:

This removes any '...shisms' not compatible with POSIX. We're not going back to pure Bourne shell, which I consider too primitive. See the individual deltas for what changed. Two major things were:

• Arithmetic notation, which I fixed with a hack: prefix every (( ... )) expression with : $.
• Simple, single bracket tests: [ ... ] instead of [[ ... ]]

The second change is to throw all code into functions, this makes testing of functions simple, as we can just source the shpec script and test functions separately. It also simplifies recursive calls to
shpec. However, recursive calls do not update the assertion and failure counters, as its internals
run in a subshell, to protect the environment.

Performance: I had a simple set of 37 assertions which run in ~12 ms on my laptop.
There's little difference between bash, ksh and dash, except that bash takes an extra 8-10 ms to start itself.

I'm still looking for the shell equivalent of python's if __name__ == '__main__':
Until then I need to trigger on the value of $0.

[AdrieanKhisbe]

That's a greate PR! :)
Just add a look about it, sound great!
(was also thinking we should make shpec a function for more flexibility and perf)

Will try to test it out in the weekend.

Could you explain what the hack about arithmetic expression does?

(about the if main. i think the way to go in bash is with the $0)

[erichs]

@hlangeveld: so awesome!

[rylnd]

😍 This looks amazing. It's quite a significant PR, so please give me some time to 1) understand it and 2) provide some feedback.

Thanks so much @hlangeveld !

[hlangeveld]

On 04/10/15 09:26, Adriean Khisbe wrote:

Could you explain what the hack about arithmetic expression does?

I think I can.

tldr; The hack just takes an assignment masquerading as an expression, but discards the string as
an argument of :, a shell builtin equivalent to true.

Detailed explanation:

(Note: In this example, I'll use the markdown convention of using ... and the four space indent
to highlight code samples.)

Let's take the very simple expression:

 : $((a=1))

It consists of two parts: : and $(( a=1 )) (arithmetic expressions are liberal about white space).

The shell builtin : is an actual command, accepts arguments, discards them, and returns status 0.
It's therefore an equivalent of true.

As : is a builtin, any side effects during its parameter substitution (which happens before it is executed)
are preserved

The arithmetic expression actually contains an assignment, and like many modern language, the value
of the assignment is equal to the value of the left hand side after assignment. Therefore,

 : $(( a=1 ))

is equivalent to:

 : 1

with a side-effect of assigning 1 to variable a. See also: (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04)

All changes to variables in an arithmetic expression shall be in effect after the arithmetic expansion, as in the parameter expansion "${x=value}".

Note, it is not fully equivalent, because an arithmetic statement will return
true (exit status 0) if its numeric value equals non-zero. Otherwise, it will be false (1).

 :  any parameter expansion not resulting in errors

will always return true (exit status 0).

A precedent can be found in very early *sh documentation;

 : ${variable:=value}

I believe this was already valid syntax for the Bourne shell, together with:

• ${var:+replacement} # if $var is set, expand to "replacement".
• ${var:-default} # expand to "default" if $var is not set (or empty)
• ${var:?error} # send message "error" to stderr if $var not set, and exit current (sub)shell

I hope I made myself clear.

Cheers,
Henk

[AdrieanKhisbe]

@hlangeveld thanks for the explanation :).
Didn't know at all about the :.
(shell features are infinite ^^)

[hlangeveld]

On 04/11/15 11:39, Adriean Khisbe wrote:

@hlangeveld https://github.com/hlangeveld thanks for the explanation :).
Didn't know at all about the |:|.
(shell features are infinite ^^)

A bit of personal history: Back in '85, I had an instructor who
challenged us to write shell scripts with a minimal amount
of calls to outside code (i.e., no exec() system calls).

Somehow that stuck with me. Since reading Michael Feathers' '... Legacy Code'
I found inspiration for making shells scripts (components) test-ready.

Even if you don't actually write a test (but you should), your code will
be better if you write it with tests in mind.

Cheers,
Henk

[rylnd]

Does this line have a purpose?

[hlangeveld]

A shell script traditionally started with just ': '. Before kernels interpreted the hasbang,
the shell would see if the first character(s) equalled ':' or ': '. In that case it would fork itself and feed itself the script.

I don't know how I ended up adding an empty comment up there.

[rylnd]

@hlangeveld all in all, this is wonderful! I've added a few comments above. Once those are resolved, we just need to update the changelog, bump the version, and merge!

[rylnd]

@hlangeveld now that shpec is a function defined as a subshell command, can you speak to whether this affects any existing issues (for better or worse), particularly #16 or #30?

[hlangeveld]

On 04/10/15 18:22, Ryland Herrick wrote:

😍 This looks amazing. It's quite a significant PR, so please give me some time to 1) understand it and 2) provide some
feedback.

Thanks for the feedback so far. Most are thinks I need to fix.
Not tonight, though.

Cheers,
Henk

[hlangeveld]

On 04/13/15 04:29, Ryland Herrick wrote:

@hlangeveld https://github.com/hlangeveld now that |shpec| is a function defined as a subshell command, can you speak to whether
this affects any existing issues (for better or worse), particularly #16 #16 or #30
#30?

With shpec redefining itself as a function this has little effect on issue #16.

The easiest way for me is to put the code executed in the tests in a subshell and test
its exit status, or to use command substitution (which implies a subshell):

 describe "example 1 ..."
   it "explain assertion"
      (
        : subshell with code
      )
      assert matcher ...
   end
 end

 describe "example 2 ..."
   it "explain assertion"
      a=$(
        : subshell with code
      )
      b=$(
        : another subshell
      )
      assert matcher referring to "$a" and/or "$b"
   end
 end

A completely different way of passing info between the framework and a project's tests would be to make
individual tests run entirely in a subshell and report results in a fixed format, to be read by the framework.
Say a single line with status, (#pass #fail "description"), followed by multiple lines of arbitrary output
from individual assertions with more detail.

[rylnd]

Closing this in favor of the newer #58