Hello :), Le ven. 6 mars 2026 à 19:18, Paul Eggert <[email protected]> a écrit : > > On 2026-03-06 08:41, Laurent Lyaudet wrote: > > sed -i or sed -ni with -e 's/a/b/g' on an empty file > > (hence no match, no replace/modification of text at all) > > modifies its timestamps... > > OK, but that's inherent to an --inplace option, no? Even a write that > changes to the same value is still a write. What's the point of that remark? I said the KEY FEATURE was about no text modification implies no timestamp modification. "a write that changes to the same value" is political talk. It doesn't change anything in the text if it is the same value. The fact that the file would be opened in write mode and that you overwrite each line one after the other if they match the grep expression is just a technical detail for one implementation not all, this is not the semantic of inplace since with grep the "array can shrink". We're not in the same context that with inplace sorting algorithms. My Bash code respect the semantic and doesn't do a write on an unmodified file.
> > It sounds like grep would need two options, say --inplace and > --no-update-timestamps-inplace-if-equal. Maybe, if you really want that inplace only means that infile is the same as outfile. You can do as you wish. Maybe it's better that way since it is more "atomic" with each part of the feature explicited. > But in that case it'd be > simpler merely to add the latter option to 'sed'. And to some extent I'm > dubious that such a special-purpose option is needed; after all, a shell > script is easy to write as-is with sed --inplace followed by cmp -s > followed by rm/mv/cp as needed. Yes it is easy, that's what I did in my linked code, but with grep instead of sed. You can do it with sed and p command, but then: Why grep is not just a convoluted alias for sed with p command?. If there is something that grep can do and sed not, then we need it in grep too. Maybe completionism would be to add the features --inplace and --no-update-timestamps-inplace-if-equal to grep and --no-update-timestamps-inplace-if-equal to sed. > > > it is certain that using fixed strings instead of regexp is way > > faster when there is one anchor > > Quite possibly, but enough faster to justify the hassle of adding, > supporting, and documenting two new options indefinitely? Let's see some > numbers. That's what I said in my second message: >... > Maybe not faster enough for adding complexity >... > to the code in the opinion of some people. I don't have the numbers. Of what I can foresee of the complexity of adding --inplace and --no-update-timestamps-inplace-if-equal options, having objective and relevant numbers would need to code the features first, since they are quite trivial, and then take probably the same amount of time, maybe more, just to have the correct benchmarks. Knowing that a for loop on two arrays at the same time with a simple "if !=" is faster than regexp matching is enough for me.
