What’s the challenge in here? Loading the text efficiently in RAM?
I don't remember exactly how long it took but I remember it being something like 30 minutes of purely waiting for the find / replace to finish on a 4 CPU core / 8 GB of memory machine. Memory wasn't an issue fortunately.
The syntax escapes me at the moment, but I'm quite sure I've used sed (or maybe awk?) in the past to do exactly that
I used "quite some time" because this happened months ago and I don't recall the exact time on the delete. I don't think deleting a line was any faster than doing a find / replace on 1 line. If sed is reading and writing the file in both cases I'd expect both to have the same performance.
For example if you're doing a SQL dump -> import, technically you could have downtime during this process to eliminate any chance of data loss. Having to wait ~30min for a command to finish is painful.
I'm not saying to go off and make this product to sell but if such a tool existed and you positioned it at $39 or whatever, if it could eliminate half an hour of downtime for a business it pays for itself. Especially if the alternative is to muck around with hex editing the file.
If 100,000 people have this problem and 3,000 of them would pay for it that's $117,000. If you spent 6 months making a super polished tool that made it easy to know exactly what's being edit (or deleting lines, etc.) that's pretty appealing. Even if the sales were half that's still solid but it could also be 5x too, who knows. Maybe you can finish such an app in 3 months instead of 6, etc.. It's also an app that mostly feels like it could reach a "done" state with little maintenance since you're editing text files which is a well known topic.