Jeff King wrote: > Perhaps we could refactor it into a > set of two functions that keep state? E.g., something like: > > test_start 'setup' > cat >expect <<EOF > ... whatever ... > EOF > test_end success > > test_start 'description' > git frob >actual && > test_cmp expect actual > test_end success > > where test_start would set up >&3 and >&4 as usual, and test_end would > check $? and report the status. The biggest problem I see is that we > never have the actual shell script snippet as a string, so we don't have > a way of printing it for "-v" (or on failure). Hmm. FWIW I don't mind this idea (to be used as an alternative to test_expect_success when quoting issues get ugly). Maybe the harness could fetch the snippet by parsing $0? (Sorry, couldn't resist. Something simpler might be possible: e.g., a special test_expect_success 'description' - <<\test_end cat >expect <<EOF ... whatever ... EOF test_end syntax.) >> I don't know: I think >> >> cat >expect <<-\EOF && >> ... >> EOF >> >> is pretty readable. The problem with sticking to > > Yeah, I almost mentioned that, but for some reason in the back of my > mind <<- is not actually portable. Perhaps I am just thinking of the > fact that perl does not support it. I seem to remember some language where the here documents would snip some well determined constant amount of whitespace from the enclosed lines. Unfortunately in the shell, that is not the rule: <<- just trims out all the leading tabs. So when expected output includes leading tabs, it is ugly again. q_to_tab <<-\EOF Like this: Q1. indented line Q2. second indented line EOF -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html