Re: [PATCH v2 10/11] test-lib: make it possible to override how test code is eval'd

[Junio C Hamano <gitster@pobox.com>]

Richard Hansen <rhansen@bbn.com> writes:

> On 2014-06-05 17:11, Junio C Hamano wrote:
> ...
>> In any case, the above explanation confuses me somewhat.  test_eval_
>> is fed a scriptlet defined for various test_expect_success tests,
>> and they are written in POSIX shells, not zsh, so wouldn't it be
>> wrong to run them as if they are zsh native scripts, following
>> non-POSIX shell syntax rules?
>
> The scriptlets in lib-prompt-tests.sh are not actually written for POSIX
> sh -- they are written in a common subset of the zsh and bash languages
> (I should document this in lib-prompt-tests.sh).
>
> We want to test how the __git_ps1 code behaves when interpreted in
> "native" zsh mode (default options), because that's how it will be used
> in the wild, so the scriptlets must be valid zsh code.  We also want to
> test how __git_ps1 behaves in native bash mode, so the scriptlets must
> also be valid bash code.  (Fortunately the similarities between the
> shells make this easy to do.)

OK.  The above all makes sense, but I think we would prefer a
solution with changes limited to lib-prompt-tests and lib-zsh
without touching lib-test-functions at all if that is the case.

> An alternative to this commit -- and I kinda like this idea so I'm
> tempted to rewrite the series -- would be to do change the form of the
> tests in lib-prompt-tests.sh to something like this:
>
>     test_expect_success 'name of test here' '
>         run_in_native_shell_mode '\''
>             scriptlet code here
>         '\''
>     '

Yeah, or even:

	prompt_test_expect success 'name of test' '
        	scriptlet code here
	'

with a helper prompt_test_expect that wraps whatever logic you will
have in run-in-native-shell-mode.

> ...
> This approach makes it clear to others that the scriptlet code is not
> actually POSIX shell code, but a common subset of multiple shell languages.
>
> What do you think?

;-)

> Ignoring t9902 for a moment, we could even stop doing that messy 'exec
> $SHELL "$0" "$@"' stuff in lib-*sh.sh and let t9903 and t9904 run under
> /bin/sh.  Then run_in_native_shell_mode() would be defined as follows:

No, let's not go there (and you stated the reason why we do not want
to yourself already ;-).