Re: [gentoo-dev] [PATCH v2 1/1] esed.eclass: new eclass

[Ionen Wolkens <ionen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On Fri, Jun 03, 2022 at 07:15:17PM -0500, Oskari Pirhonen wrote:
[snip[
> Testing for (in)equality between pre- and post-sed contents is
> reasonable enough in most cases. This time, though, it would fail to
> detect anything has changed since the pre-sed contents have their NULL's
> unintentionally stripped, whereas the post-sed contents have them
> intentionally stripped.
>
> While I personally don't think that running sed on binary files is a
> good idea in the first place, it's still relevant since the end result
> would be an incorrect answer to the question of "Did sed actually do
> anything?".

Yeah one of the primary motivation to silence this was elsewhere, I
don't think silencing matters for esed and if binary files are being
modified may as well use sed(1) directly instead (this is something
that'd need to be more intensively verified on bumps than with esed
anyway).

Use is also very uncommon, although sed is still "handy" when changing
just 1 instruction and want to avoid an extra dependency on a proper
binary patching method.
 
> On the other hand, saving a set of pre- and post-sed hashes like Ulrich
> suggested would give the expected result.

If really wanted to solve this yes, although it may make sense to say
this eclass is not for binary files. The talk to add bash-only "erepl"
makes it rather difficult to preserve nulls (mapfile silently strip \0
without even a warning). mapfile -d '' could allow to restore them
but ideally want to iterate on lines to do per-line pattern matches.
Is it possible to hack away something to preserve? Probably.. but it's
going to make this messy and I'm not sure it's worth it.

erepl is also worse because they'll be lost in output and not just
during comparison.

-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]