I want to add this to the hcaccess file, but it's not there, where the tutorial says

[g1smd]

I want to do the following (from a tutorial).

# redirects any URL that includes: record_company.php/password_forgotten.php
RedirectMatch Permanent ^/(.*[record_company.php]+)/(password_forgotten.php)$ /page_not_found.php

That's quite a dodgy tutorial you've found.

The pattern [record_company.php]+ will match URL requests containing:
rcrdcmpyhhpp
rrrrrrrrrrdddddd
compcompcompyyyycomp
and an infinite number of other requests which contain any of the letters "r e c o d m p a n y h" and/or an underscore and/or period.

The leading .* pattern also has the effect of the pattern matching "anything of any length, or nothing" as a prefix to that. This means that mod_rewrite will make several thousand "back off and retry" attempts at pattern matching for every URL request handled by your server.

When you consider that a single page might have several dozen elements (images, CSS, JS, etc), this code is almost a self-inflicted denial of service for all of your visitors.

# redirects any URL that includes: /images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RedirectMatch Permanent ^/(.*[images]+)/(wp-.*\.php)$ /page_not_found.php

This code has the same problem.

The pattern [images]+ allows any URL request containing the letters "i m a g e s" in any order and any amount, and the preceding .* pattern again causes the rule to try thousands of "back of and retry" pattern matching attempts for each requested URL. The second .* pattern multiplies the number "back off and retry" attempts to an even greater amount, slowing the server yet more.

So, a request containing zzzz56789/3edt5t/eeeegggggimimimim/wp-bbbbbb.php will eventually match the rule after very many pattern matching attempts, instead of immediately triggering a 404 response after one try.

Once a match has been found, there's a second fatal flaw. This code does not return a 404 response. It returns a 301 redirect to a new URL. The browser then has to make a new HTTP request for the new URL, the pattern matching runs again (and this time fails) and then a page is brought up with the "Not Found" error message. This page is likely displayed with "200 OK" status, as it has been directly requested by the browser as a new URL instead of being returned by Apache's internal ErrorDocument handling.

You likely can't see the bad effects of what is going on inside your server, because all those attempts do eventually bring up an error message. Look again using Live HTTP Headers for Firefox and you'll immediately see the problems.

This code is likely to force many users into an early server upgrade as it is very very inefficient. It could also be harmful to search rankings if external sites maliciously mass-linked to certain "invented" path-part patterns as if they were real URLs supposedly active on your site. It is links that define URLs. It's up to the server to return the correct HTTP status code for those requests.

This code does not do so, has many dangerous (to the wellbeing of your site) elements and should not be used in its present form.