Thanks for your answers :) Le jeu. 5 mars 2026 à 20:56, Paul Eggert <[email protected]> a écrit : > That implementation should use cmp -s, instead of calling wc twice, > since it's possible for the output of grep to differ from its input even > though both contain the same number of newlines.
Thanks I didn't think about using cmp -s, because I never use this command. But I did knew before coding that grep can also modify lines by adding filenames or line numbers as prefix, or the other way around by keeping only the matched part of the line in the result. My code is just a small solution for what I needed when I did it. I knew from the start that the --inplace option to grep would have to do better than my simple code to handle all other options. Since you suggested to use cmp -s, I will test it and see if at least my code can be made bug free when other options are supplied to the command grep inside my function. > > My initial reaction is that there's little need for "grep --inplace EXPR > FILE", as one can already use "sed -ni /EXPR/p file" to get that effect. No, that's not true. I coded my function primarily because at the start of the development of my project, I did batch processing of all files with sed commands, and all had modified timestamps afterwards. I just retested and that's still true. 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... I didn't knew about that funny syntax /EXPR/p, and tested: $ stat -c %Y bla | date Fri Mar 6 17:32:25 CET 2026 $ sed -ni /s/a/b/g/p bla $ stat -c %Y bla | date Fri Mar 6 17:32:33 CET 2026 $ So, as you see, that is also not a solution. > We already have "grep -F --line-regexp 'STRING'", which asks that the > fixed string matches both start and end. So it sounds like you're asking > for new options (say, --start-line-regexp and --end-line-regexp) which > anchor only the start and end, and are equivalent to "grep '^S'" and > "grep 'S$'" where S is the escaped version of STRING. > > It shouldn't be too hard to add that, if there's a real need and if > there's a significant performance boost. (Have you measured the > performance?) Thanks for seeing an interest into my last suggestion. I DO have a real need currently, since I use it with an anchor at the end of the string only. I cannot measure the performance gain. Comparing Bash code with C code would be slightly stupid. But it is certain that using fixed strings instead of regexp is way faster when there is one anchor. In my case, it would replace all the complicated stuff of regexp with just a loop going backward from end of fixed string and end of each line to see if it matches. So no test is needed to know that it will be way faster. Maybe not faster enough for adding complexity to the code in the opinion of some people. But I always had a taste for "creeping featurism" and now that the L3 cache of CPUs is larger than the size of HDDs of my young, I consider that minimalism can be less tight :).
