I did this
Run ./tests/runtests.pl 1067 (can be most/any tests).
The test fails.
I expected the following
Test passing.
curl/libcurl version
(any) / git HEAD (acd90af)
curl 7.75.1-DEV (x86_64-apple-darwin19.6.0) libcurl/7.75.1-DEV OpenSSL/1.1.1i zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.0 libpsl/0.21.1 (+libicu/67.1) nghttp2/1.43.0 librtmp/2.3
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli Debug HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL TLS-SRP TrackMemory UnixSockets zstd
operating system
(any)
The reason for test to fail is having a .curlrc on the machine which contains options that alter curl's behaviour, and making output different than expected by tests. The solution is to disable loading .curlrc in test contexts.
This may not cover all cases (and may have unintended side-effects, and/or this may have a more elegant solution), anyway this patch resolves the above basic (and possibly some more) cases:
diff --git a/tests/runtests.pl b/tests/runtests.pl
index ddee02ad3..2e720c5fc 100755
--- a/tests/runtests.pl
+++ b/tests/runtests.pl
@@ -891,7 +891,7 @@ sub verifyhttp {
}
$flags .= "\"$proto://$ip:$port/${bonus}verifiedserver\"";
- my $cmd = "$VCURL $flags 2>$verifylog";
+ my $cmd = "$VCURL --disable $flags 2>$verifylog";
# verify if our/any server is running on this port
logmsg "RUN: $cmd\n" if($verbose);
@@ -968,7 +968,7 @@ sub verifyftp {
}
$flags .= "\"$proto://$ip:$port/verifiedserver\"";
- my $cmd = "$VCURL $flags 2>$verifylog";
+ my $cmd = "$VCURL --disable $flags 2>$verifylog";
# check if this is our server running on this port:
logmsg "RUN: $cmd\n" if($verbose);
@@ -1034,7 +1034,7 @@ sub verifyrtsp {
# currently verification is done using http
$flags .= "\"http://$ip:$port/verifiedserver\"";
- my $cmd = "$VCURL $flags 2>$verifylog";
+ my $cmd = "$VCURL --disable $flags 2>$verifylog";
# verify if our/any server is running on this port
logmsg "RUN: $cmd\n" if($verbose);
@@ -1177,7 +1177,7 @@ sub verifyhttptls {
}
$flags .= "\"https://$ip:$port/verifiedserver\"";
- my $cmd = "$VCURL $flags 2>$verifylog";
+ my $cmd = "$VCURL --disable $flags 2>$verifylog";
# verify if our/any server is running on this port
logmsg "RUN: $cmd\n" if($verbose);
@@ -1284,7 +1284,7 @@ sub verifysmb {
$flags .= $extra;
$flags .= "\"$proto://$ip:$port/SERVER/verifiedserver\"";
- my $cmd = "$VCURL $flags 2>$verifylog";
+ my $cmd = "$VCURL --disable $flags 2>$verifylog";
# check if this is our server running on this port:
logmsg "RUN: $cmd\n" if($verbose);
@@ -1345,7 +1345,7 @@ sub verifytelnet {
$flags .= $extra;
$flags .= "\"$proto://$ip:$port\"";
- my $cmd = "echo 'verifiedserver' | $VCURL $flags 2>$verifylog";
+ my $cmd = "echo 'verifiedserver' | $VCURL --disable $flags 2>$verifylog";
# check if this is our server running on this port:
logmsg "RUN: $cmd\n" if($verbose);
@@ -4022,7 +4022,7 @@ sub singletest {
}
if(!$tool) {
- $CMDLINE="$CURL";
+ $CMDLINE="$CURL --disable";
}
my $usevalgrind;
I did this
Run
./tests/runtests.pl 1067(can be most/any tests).The test fails.
I expected the following
Test passing.
curl/libcurl version
(any) / git HEAD (acd90af)
curl 7.75.1-DEV (x86_64-apple-darwin19.6.0) libcurl/7.75.1-DEV OpenSSL/1.1.1i zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.0 libpsl/0.21.1 (+libicu/67.1) nghttp2/1.43.0 librtmp/2.3
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli Debug HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL TLS-SRP TrackMemory UnixSockets zstd
operating system
(any)
The reason for test to fail is having a
.curlrcon the machine which contains options that alter curl's behaviour, and making output different than expected by tests. The solution is to disable loading.curlrcin test contexts.This may not cover all cases (and may have unintended side-effects, and/or this may have a more elegant solution), anyway this patch resolves the above basic (and possibly some more) cases: