IFS was modified by run() becoming '\n' and so relying to its bash default
was failing tests.
Also some wrong tests corrected because was relying on this behavior to pass.
Fix#89
The outermost command—i.e. the line that failed inside the test case function itself—is more likely to be meaningful at a glance than the innermost command, which might be e.g. the implementation of a helper assertion.
Tested on GNU `sed --posix`.
From `info sed`:
`\+'
As `*', but matches one or more. It is a GNU extension.
`\CHAR'
Matches CHAR, where CHAR is one of `$', `*', `.', `[', `\', or `^'.
Note that the only C-like backslash sequences that you can
portably assume to be interpreted are `\n' and `\\'; in particular
`\t' is not portable, and matches a `t' under most implementations
of `sed', rather than a tab character.
The `((x++))` syntax is shorthand for `let x++`. According to `help let`:
If the last ARG evaluates to 0, let returns 1; 0 is returned
otherwise.
Thus the exit status of the expression `x=0; let x++` is 1, since the post-increment `++` operator evaluates to the value of the variable before incrementing.
In Bash 4, this non-zero exit status properly triggers `set -e`'s error trap, but in Bash 3 it does not. That's why the tests were passing on OS X (Bash 3) but not Linux (Bash 4).
We can work around the problem by choosing an incrementation expression that never evaluates to 0, such as `+=` or the pre-increment `++` operator. For consistency and clarity, I've changed to `x+=1` everywhere.
Ref. #25, #27
