[PATCH 1/2] test/T030-config: Separate stdout and stderr output

[PATCH 1/2] test/T030-config: Separate stdout and stderr output

[Luis Ressel]

POSIX doesn't specify the flushing behaviour of the STDOUT stream, so
it's invalid to assume a particular order between the stdout and stderr
output. The current test breaks on musl due to this.
---
 test/T030-config.sh | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/test/T030-config.sh b/test/T030-config.sh
index f36695c6..eba2e0e7 100755
--- a/test/T030-config.sh
+++ b/test/T030-config.sh
@@ -43,7 +43,8 @@ notmuch config set foo.nonexistent
 test_expect_equal "$(notmuch config get foo.nonexistent)" ""
 
 test_begin_subtest "List all items"
-notmuch config list 2>&1 | notmuch_config_sanitize > OUTPUT
+notmuch config list > STDOUT 2> STDERR
+printf "%s\n====\n%s\n" "$(< STDOUT)" "$(< STDERR)" | notmuch_config_sanitize > OUTPUT
 
 if [ "${NOTMUCH_GMIME_MAJOR}" -lt 3 ]; then
     config_gpg_path="crypto.gpg_path=gpg
@@ -51,7 +52,6 @@ if [ "${NOTMUCH_GMIME_MAJOR}" -lt 3 ]; then
 fi
 
 cat <<EOF > EXPECTED
-Error opening database at MAIL_DIR/.notmuch: No such file or directory
 database.path=MAIL_DIR
 user.name=Notmuch Test Suite
 user.primary_email=test_suite@notmuchmail.org
@@ -65,6 +65,8 @@ foo.list=this;is another;list value;
 built_with.compact=something
 built_with.field_processor=something
 built_with.retry_lock=something
+====
+Error opening database at MAIL_DIR/.notmuch: No such file or directory
 EOF
 test_expect_equal_file EXPECTED OUTPUT
 
-- 
2.21.0

[PATCH 2/2] Prepend regerror() messages with "regexp error: "

[Luis Ressel]

The exact error messages returned by regerror() aren't standardized;
relying on them isn't portable. Thus, add a a prefix to make clear that
the subsequent message is a regexp parsing error, and only look for this
prefix in the test suite, ignoring the rest of the message.
---
 lib/regexp-fields.cc      | 4 ++--
 test/T650-regexp-query.sh | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/regexp-fields.cc b/lib/regexp-fields.cc
index 084bc8c0..f50da9a3 100644
--- a/lib/regexp-fields.cc
+++ b/lib/regexp-fields.cc
@@ -35,9 +35,9 @@ compile_regex (regex_t &regexp, const char *str)
     if (err != 0) {
 	size_t len = regerror (err, &regexp, NULL, 0);
 	char *buffer = new char[len];
-	std::string msg;
+	std::string msg = "Regexp error: ";
 	(void) regerror (err, &regexp, buffer, len);
-	msg.assign (buffer, len);
+	msg.append (buffer, len);
 	delete[] buffer;
 
 	throw Xapian::QueryParserError (msg);
diff --git a/test/T650-regexp-query.sh b/test/T650-regexp-query.sh
index 4085340f..31b3d036 100755
--- a/test/T650-regexp-query.sh
+++ b/test/T650-regexp-query.sh
@@ -137,10 +137,10 @@ EOF
 test_expect_equal_file EXPECTED OUTPUT
 
 test_begin_subtest "regexp error reporting"
-notmuch search 'from:/unbalanced[/' 1>OUTPUT 2>&1
+notmuch search 'from:/unbalanced[/' 2>&1 | sed -e '/^A Xapian/ s/[^:]*$//' > OUTPUT
 cat <<EOF > EXPECTED
 notmuch search: A Xapian exception occurred
-A Xapian exception occurred parsing query: Invalid regular expression
+A Xapian exception occurred parsing query: Regexp error:
 Query string was: from:/unbalanced[/
 EOF
 test_expect_equal_file EXPECTED OUTPUT
-- 
2.21.0

Re: [PATCH 1/2] test/T030-config: Separate stdout and stderr output

[David Bremner]

Luis Ressel <aranea@aixah.de> writes:

> POSIX doesn't specify the flushing behaviour of the STDOUT stream, so
> it's invalid to assume a particular order between the stdout and stderr
> output. The current test breaks on musl due to this.

Series pushed. Thanks for working through those changes with us.

d

Re: [PATCH 1/2] test/T030-config: Separate stdout and stderr output

[Tomi Ollila]

On Tue, Mar 12 2019, David Bremner wrote:

> Luis Ressel <aranea@aixah.de> writes:
>
>> POSIX doesn't specify the flushing behaviour of the STDOUT stream, so
>> it's invalid to assume a particular order between the stdout and stderr
>> output. The current test breaks on musl due to this.
>
> Series pushed. Thanks for working through those changes with us.

That was fast -- I did not had time to LGTM those (Well, after these years
you probably guessed my response alread ;D)

Tomi

>
> d