1 |
On Fri, Jun 03, 2022 at 07:15:17PM -0500, Oskari Pirhonen wrote: |
2 |
[snip[ |
3 |
> Testing for (in)equality between pre- and post-sed contents is |
4 |
> reasonable enough in most cases. This time, though, it would fail to |
5 |
> detect anything has changed since the pre-sed contents have their NULL's |
6 |
> unintentionally stripped, whereas the post-sed contents have them |
7 |
> intentionally stripped. |
8 |
> |
9 |
> While I personally don't think that running sed on binary files is a |
10 |
> good idea in the first place, it's still relevant since the end result |
11 |
> would be an incorrect answer to the question of "Did sed actually do |
12 |
> anything?". |
13 |
|
14 |
Yeah one of the primary motivation to silence this was elsewhere, I |
15 |
don't think silencing matters for esed and if binary files are being |
16 |
modified may as well use sed(1) directly instead (this is something |
17 |
that'd need to be more intensively verified on bumps than with esed |
18 |
anyway). |
19 |
|
20 |
Use is also very uncommon, although sed is still "handy" when changing |
21 |
just 1 instruction and want to avoid an extra dependency on a proper |
22 |
binary patching method. |
23 |
|
24 |
> On the other hand, saving a set of pre- and post-sed hashes like Ulrich |
25 |
> suggested would give the expected result. |
26 |
|
27 |
If really wanted to solve this yes, although it may make sense to say |
28 |
this eclass is not for binary files. The talk to add bash-only "erepl" |
29 |
makes it rather difficult to preserve nulls (mapfile silently strip \0 |
30 |
without even a warning). mapfile -d '' could allow to restore them |
31 |
but ideally want to iterate on lines to do per-line pattern matches. |
32 |
Is it possible to hack away something to preserve? Probably.. but it's |
33 |
going to make this messy and I'm not sure it's worth it. |
34 |
|
35 |
erepl is also worse because they'll be lost in output and not just |
36 |
during comparison. |
37 |
|
38 |
-- |
39 |
ionen |