G'day GrandFather,

++ Thanks for your input.

I did possibly end up (implicitly) suggesting that speed was the all-important factor.

I have seen innumerable cases where regexes have been used to test exact matches (/^some_string$/), test if strings start with some token (/^some_token/), and so on. As I said originally, "Perl's string handling functions (and operators) are, in my experience, substantially faster than achieving the same functionality with regexes."; as such, reaching for a regex first has become something of an annoyance for me.

The OP had asked "How it can be acheived without escapeing the special chars?" and I rather thought that was implicit in my "rindex" code. Perhaps I should have highlighted that.

I also answered the OP's title question, "How to remove everything after last occurrence of a string?". Again, I didn't highlight that.

I hadn't really considered the maintainability aspect but, I agree, the "rindex" code is easily understandable and works in all versions of Perl5; that's not to say that I shy away from regexes (see "Syntax-highlight Non-Perl Code for HTML"). Furthermore, if those maintaining the code are expected to have a solid grounding in regexes, then I'd say that neither solution is particularly complex and both are equally maintainable (a YMMV situation).

The OP may have a very specific reason for choosing a regex solution; however, if not, why not choose an alternative that's three times faster.

Do you still want to go with a regex solution? :-)

No | Yes, because (in this case at least) the rindex solution is wrong.

How can one say any result is incorrect if the OPer has specified no clear set of requirements for results? I admit this is tricky, but one can say the use of s/// in the OPed example code implies that the string operand should be unchanged if no version substring match is found. _rindex() in the code here fails to do this.

It's easy enough to define an rindex-based function that handles the no-match case (and it might even be a bit faster). But the argument seems to be that one should avoid using and learning about regexes because they are a bit arcane (indeed, regexes are the most counter-intuitive programming construct I know) and may vary a bit from language to language. This argument can be extended to languages themselves: We should not use Perl because it's not Python; not use Python because it's not C++; not use C++ because it's not...

To answer a use-case such as that described in the OP, I tend to reach first for a regex solution because it most clearly represents and achieves the required operation, not because it is the fastest (although sometimes it is). Implementing the required operation in terms of index/rindex, substr, etc., is possible, but may have its own pitfalls and drawbacks in terms of basic correctness, readability and maintainability.

These are all my own very personal preferences; others may differ.

Update: Rats... Trashed the thrust of the entire post by getting the very first word wrong. Oh, well...

It comes down to choosing the right tool for the task at hand. That is an art in itself. Often a regex is the right tool to solve a tricky matching problem. Sometimes something like index is the tool to use for a simple matching problem or where speed is critical. My main point is that raw execution speed should not be the first consideration when choosing tools to solve a problem. Demonstrable correctness and maintainability should come first and often go hand in hand. At this point the discussion doesn't have much to do with the OP or the specific implementation of any reply.

My reply was addressing what could be seen as a "speed first" approach to coding being advocated by kcott's reply. Ken is an experienced coder so he can skip a few iterations ahead to get a solution that is both clean and quick. That is something that comes with experience, often bitter, so I thought a heads up for the less experienced was in order.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Demonstrable correctness and maintainability should come first ... My reply was addressing what could be seen as a "speed first" approach to coding being advocated

Strongly agree! See: on Code Optimization

Sadly, there seems to have been an increase lately in monks asking for faster code without explaining why speed matters for their problem and without providing a benchmark. Some reacted appallingly on being given your well-meaning advice, one even deleting all his content and leaving the monastery in a huff.