randall.s.becker@xxxxxxxxxx writes: > From: "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> > > Replaced subtest 15 (CONTENT_LENGTH overflow ssite_t) use of /dev/zero > with yes and a translation of its result to a stream of NULL. This is > a more portable solution. > > Signed-off-by: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> > --- > t/t5562-http-backend-content-length.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/t/t5562-http-backend-content-length.sh b/t/t5562-http-backend-content-length.sh > index 90d890d02..b8d1913e5 100755 > --- a/t/t5562-http-backend-content-length.sh > +++ b/t/t5562-http-backend-content-length.sh > @@ -143,14 +143,14 @@ test_expect_success GZIP 'push gzipped empty' ' > > test_expect_success 'CONTENT_LENGTH overflow ssite_t' ' > NOT_FIT_IN_SSIZE=$(ssize_b100dots) && > - env \ > + yes | tr "y" "\\0" | env \ I do not quite get this use of tr. The original feeds a stream of NULs out of /dev/zero to the command; the yes-to-tr pipe instead feeds a stream of alternating NUL and LF. Does the actual bytes fed to the consumer make any difference? If not, perhaps we can use 'yes' as-is? > CONTENT_TYPE=application/x-git-upload-pack-request \ > QUERY_STRING=/repo.git/git-upload-pack \ > PATH_TRANSLATED="$PWD"/.git/git-upload-pack \ > GIT_HTTP_EXPORT_ALL=TRUE \ > REQUEST_METHOD=POST \ > CONTENT_LENGTH="$NOT_FIT_IN_SSIZE" \ > - git http-backend </dev/zero >/dev/null 2>err && > + git http-backend >/dev/null 2>err && > grep "fatal:.*CONTENT_LENGTH" err > '
