mbland / go-script-bash / 283 / 1
95%
master: 95%

DEFAULT BRANCH: master
Ran
Files 38
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 94.649% (+1.3%) from 93.395%
283.1

push

travis-ci

mbland 
log: Extract helper script to fix Windows breakage

PR #28 introduced the `stack_trace_item` test helper function so that tests
could validate expected stack trace output without hardcoding line numbers. I
failed to notice that this behavior was broken on Windows, due to leading
whitespace getting stripped and CRLF line endings not being handled by the
`while read -r line` loop.

The fix for the whitespace was easy. Per the following, setting `IFS=` did the
trick:

https://stackoverflow.com/questions/29689172/bash-read-line-does-not-read-leading-spaces/29689199#2968919

However, adding the following as the first line of the loop by itself wasn't
enough:

    line="${line%$'\r'}"

It turned out that when the `stack-trace-item` file was getting written, it
would replace this line with:

    line="${line%^M}";

where `^M` was the literal carriage return character, not the Bash string.
Somehow this was causing the line to continue to retain its trailing carriage
return, causing the tests to continue to fail.

I only started to figure this out after adding some `echo` statements to print
things to standard error, followed by one of:

    | sed -n l >&2
    | od -A n -vt c >&2

per:

https://unix.stackexchange.com/questions/213504/how-to-print-control-characters-with-escape-sequences/213510#213510

Eventually I realized it made sense to break out the script anyway, as it
wasn't being customized by the `stack_trace_item` function. Now the tests all
pass on Windows.

1645 of 1738 relevant lines covered (94.65%)

123.94 hits per line

Source Files on job 283.1