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

Tom Russello <tom.russello@grenoble-inp.org> writes:

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.

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-<.

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>".