Re: [RFC PATCH 05/21] t3404: work around platform-specific behaviour on macOS 10.15

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Oct 3, 2024, 22:22 UTC
Message-ID: <CAPig+cSuXojVPeVE_0HFwrQQqYn-SwCvHQ9yG+c8H1dgaH00pA@mail.gmail.com>
In-Reply-To: <cf2ad192-928d-4bc6-974f-da5b217fba30@gmail.com>

On Thu, Oct 3, 2024 at 11:16 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 13 quoted lines

> On 02/10/2024 22:43, Eric Sunshine wrote:
> > On Wed, Oct 2, 2024 at 11:17 AM Patrick Steinhardt <ps@pks.im> wrote:
> >> Two of our tests in t3404 use indented HERE docs where leading tabs on
> >> some of the lines are actually relevant. The tabs do get removed though,
> >> and we try to fix this up by using sed(1) to replace leading tabs in the
> >> actual output, as well. But on macOS 10.15 this doesn't work as expected
> >> and we somehow keep the tabs around in the actual output.
> >
> > I presume this nebulous explanation is due to the fact that the reason
> > why macOS 10.15 exhibits this anomalous behavior is not yet known?
>
> I suspect that the problem is that we use "\t" which is non-standard
> rather than a literal tab character in the sed expression.

Ah yes. The `sed` on macOS 10.15 would have been of an older BSD-lineage than the more modern macOS versions, so that makes sense. It wouldn't be a bad idea for the commit message to mention something along those lines.

(I always use literal TAB with `sed` for this precise reason, which may explain why my eyes skipped right over the non-standard use of "\t" or I just wasn't paying close enough attention, which is equally likely.)