diff options
author | Kyle J. McKay <mackyle@gmail.com> | 2014-04-11 01:28:19 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-04-11 13:21:56 -0700 |
commit | ff7a1c677a88eda9a24489676052f0631a6b7fc8 (patch) | |
tree | 529df928280063d90b02de32b895140017b76bc3 /t/t7408-submodule-reference.sh | |
parent | Git 1.8.5.5 (diff) | |
download | tgif-ff7a1c677a88eda9a24489676052f0631a6b7fc8.tar.xz |
test: fix t5560 on FreeBSD
Since fd0a8c2e (first appearing in v1.7.0), the
t/t5560-http-backend-noserver.sh test has used a backslash escape
inside a ${} expansion in order to specify a literal '?' character.
Unfortunately the FreeBSD /bin/sh does not interpret this correctly.
In a POSIX compliant shell, the following:
x='one?two?three'
echo "${x#*\?}"
Would be expected to produce this:
two?three
When using the FreeBSD /bin/sh instead you get this:
one?two?three
In fact the FreeBSD /bin/sh treats the backslash as a literal
character to match so that this:
y='one\two\three'
echo "${y#*\?}"
Produces this unexpected value:
wo\three
In this case the backslash is not only treated literally, it also
fails to defeat the special meaning of the '?' character.
Instead, we can use the [...] construct to defeat the special meaning
of the '?' character and match it exactly in a way that works for the
FreeBSD /bin/sh as well as other POSIX /bin/sh implementations.
Changing the example like so:
x='one?two?three'
echo "${x#*[?]}"
Produces the expected output using the FreeBSD /bin/sh.
Therefore, change the use of \? to [?] in order to be compatible with
the FreeBSD /bin/sh which allows t/t5560-http-backend-noserver.sh to
pass on FreeBSD again.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t7408-submodule-reference.sh')
0 files changed, 0 insertions, 0 deletions