Re: sed on binary files

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> According to Gary V. Vaughan on 10/1/2008 10:09 PM:
>>> I'm working on making m4 1.6 transparently handle NUL,
>>
>> Excellent!  I made an attempt to do that myself on the 2.0 branch some
>> years ago, but it didn't go well so I never committed...
>
> The argv_ref branch already does this; it is just a matter of finishing
> porting it to branch-1.6 and master (and in the process of that porting, I
> discovered that the tests I wrote worked fine under GNU sed but died under
> Solaris 10).
>
>>> or can have false positives (if both
>>> stderr and expected error are normalized, then regressions involving
>>> added
>>> or missing NUL are not detected).  I don't want to require perl for just
>>> this one test; m4 seems fundamental enough to keep the testsuite
>>> restricted to the GNU coding standards set of tools.
>>
>> I'd be inclined to do that in C.  A few lines should be sufficient to
>> write a minimal filter that writes '\' '0' or '^' '@' to output whenever
>> a NUL byte arrives?
>
> Actually, I'm a bit lazy - I guess I'm okay with false positives on
> Solaris when using deficient sed, so long as we can also run on Solaris
> with GNU sed.  So I'm installing this patch, which lets the user select
> the right sed, as well as passing both files through sed (a no-op for GNU
> sed, but strips NUL bytes equally for Solaris sed).  (At any rate, it was
> easier to code than searching for a tr that handles NUL).
>
> Should I also modify configure.ac to call AC_PROG_SED, and feed that as
> the default for $SED in the check script?  (The master branch is currently
> the only branch that uses $SED, thanks to libtool.)

Hi Eric,

You could also just skip the affected tests when configure
fails to find an appropriate sed command.

In general, I prefer to skip tests than to get false positives,
since that decreases the likelihood of problem reports ;-)