Fix handling escaped delimiter for ex_range function

[jbgg]

Function search_init removes escape character if it escapes a delimiter, but it should consider when an backslash character is not an escape character (this occurs when two backslash). In latter case the escape character should be included in re string.

This patch can be tested with the following commands. $ printf '%s\n' '\' > test.txt $ printf '%s\n' '/\\/' 'q' | ex test.txt

Before this patch the previous command gives 'Pattern not found', because the last two caracters of the command becomes the single delimiter in the regular expression, i.e. it didn't recognize the delimiter.

[lichray]

Looks like an issue. @leres, do you recall any reason for not making this case work?

[jbgg]

You can see other part of code where it has to do the same thing (removing the escape character of delimiter), for instance https://github.com/lichray/nvi2/blob/main/ex/ex_global.c#L115 and https://github.com/lichray/nvi2/blob/main/ex/ex_subst.c#L118. Thoses cases are ok.

I was watching the old changes of nvi source code. "ex_global" was changed in this commit: https://repo.or.cz/nvi.git/commitdiff/635f2de90932bd07513114e37e6b400eba7cd17c, "ex_subst" was changed earlier: https://repo.or.cz/nvi.git/commitdiff/74097395704ba10baf44b157c2b4c4e2dde2ff84?hp=b363512514bc45e3b3c814c7dd9dc7371c1008d1.

The next question is, there is another place where it should be changed?

[leres]

Looks like an issue. @leres, do you recall any reason for not making this case work?

I don't think I knew about that issue?

[lichray]

I don't think I knew about that issue?

I mean, whether it is a bug that needs to be kept for historical reasons. I guess not if you did not know about it.

[lichray]

Thanks for the fix.