Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

[Junio C Hamano <gitster@pobox.com>]

Tom Russello <tom.russello@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 <author@example.com> from line 'From: A <author@example.com>'
    (mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
    (mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
    Dry-OK. Log says:
    Server: relay.example.com
    MAIL FROM:<from@example.com>
    RCPT TO:<to@example.com>
    RCPT TO:<cc@example.com>
    ...
    To: to@example.com
    Cc: cc@example.com,
            A <author@example.com>,
            One <one@example.com>,
            two@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-id@example.com>
    References: <unique-message-id@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 (cc@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:
cc@example.com," it is clear it was the first one output for Cc: and
diferent from "A <author@example.com>".