Tom Russello <tom.russe...@grenoble-inp.org> writes:
> +# Check if two files have the same content, non-order sensitive
> +test_cmp_noorder () {
> + sort $1 >$1;
Here is what I think happens:
0) the shell parses this command line;
1) the shell notices that the output has to go to $1;
2) the shell does open(2) of $1,
3) the shell spawns "sort" with a single argument, with its
output connected to the file descriptor obtained in 2).
Because "$1" becomes an empty file at 2), "sort" reads nothing and
writes nothing.
> + sort $2 >$2;
> + return $(test_cmp $1 $2)
What is this return doing? I would understand if it were just
test_cmp $1 $2
Of course, all the places you use test_cmp_noorder are happy when
this function returns 0/success, and because $1 and $2 at this point
are both empty files and test_cmp will not say anything to its
standard output, the return will just yield 0/success to the caller
of the function, so it is likely that with this patch t9001 would
have passed for you, but that is not necessarily a good thing X-<.
> @@ -269,7 +276,7 @@ test_expect_success $PREREQ 'Show all headers' '
> -e "s/^\(Message-Id:\).*/\1 MESSAGE-ID-STRING/" \
> -e "s/^\(X-Mailer:\).*/\1 X-MAILER-STRING/" \
> >actual-show-all-headers &&
> - test_cmp expected-show-all-headers actual-show-all-headers
> + test_cmp_noorder expected-show-all-headers actual-show-all-headers
> '
It is dubious that it is a good idea to blindly sort two files and
compare, especially because expected-show-all-headers is actually
something like this:
cat >expected-show-all-headers <<\EOF
0001-Second.patch
(mbox) Adding cc: A <aut...@example.com> from line 'From: A
<aut...@example.com>'
(mbox) Adding cc: One <o...@example.com> from line 'Cc: One
<o...@example.com>, t...@example.com'
(mbox) Adding cc: t...@example.com from line 'Cc: One <o...@example.com>,
t...@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<f...@example.com>
RCPT TO:<t...@example.com>
RCPT TO:<c...@example.com>
...
To: t...@example.com
Cc: c...@example.com,
A <aut...@example.com>,
One <o...@example.com>,
t...@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
In-Reply-To: <unique-message...@example.com>
References: <unique-message...@example.com>
Result: OK
EOF
We do want to see MAIL FROM: as the first thing we give to the
server, followed by RCPT TO:, followed by the headers.
I am having a hard time guessing what prompted you to sort the
output, i.e. what problem you were trying to solve. It cannot be
because addresses on a list (e.g. Cc:) could come out in an
indeterministic order, because the address that a test expects to be
the first (c...@example.com in the above example) may not appear as
the first one, but in the textual output it _is_ shown differently
from the remainder (i.e. even if you sort, from "Cc:
c...@example.com," it is clear it was the first one output for Cc: and
diferent from "A <aut...@example.com>".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
