summaryrefslogtreecommitdiff
path: root/t/t1509
diff options
context:
space:
mode:
authorLibravatar Kyle J. McKay <mackyle@gmail.com>2014-04-11 01:28:19 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-04-11 13:21:56 -0700
commitff7a1c677a88eda9a24489676052f0631a6b7fc8 (patch)
tree529df928280063d90b02de32b895140017b76bc3 /t/t1509
parentGit 1.8.5.5 (diff)
downloadtgif-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/t1509')
0 files changed, 0 insertions, 0 deletions