Richard Hansen <rhansen@xxxxxxx> 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 ;-).
--
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