You can try if you want. If you attack the problem directly opening an editor, I assure you, it will certainly be not so simple.
I can tell that, because it's what I've done. And I must say I lost almost a complete day at work trying to resolve this. Each time, I made a try, each time I was close, but not on the solution. There was also, many small problems around that make me lose more than two days for this problem.
Why after two days did I was unable to resolve this problem which seems so simple?
What was my behaviour (workflow)?
1. Think
2. Write the program
3. Try the program
4. Verify the result
5. Found a bug
6. Resolve the bug
7. Go to the third step
And this is the *standard* workflow for computer engineer. The flaw came from the first step.
I thought about how to resolve the problem but with the eyes of a *pragmatic engineer*. I was saying:
> That should be a simple perl search and replace program.
> Let's begin to write code
This is the second sentence that was plainly wrong. Because of old external errors I started in the wrong direction. And the workflow did not work from this entry point.
Let's have a look at the *engineer workflow*. In fact, it is a simple algorithm which start from some point, and ameliorate himself at each step until it reach a solution. The key point is, you have a bad start, you can potentially never reach a solution point.
## spoiler
In the end, the program should be a simple list of search and replace:
It should seems a bit paradoxal, but sometimes the most pragmatic approach to a pragmatic problem is to use the theoretical methodology. Not the commonly accepted pragmatic one. This simple experience prove this point.