I don't like the idea of configuring pm (or anything else) using a programming language. So I would try nix first if I feel that I need it. However I don't.
Yes, but for a very specific case. I used to write highly portable scripts that could be executed in different environments (various linux distros, including minimal containers, freebsd and even solaris 10). I couldn't use bash, perl, python and even gawk. Only POSIX shell (I always tested my scripts with dash and ksh93, for solaris 10 compatibility - with its jsh), portable awk (tested with original-awk, gawk and mawk) and portable sed (better forget it if you need to support solaris).
Before that I didn't understand why should I need awk if I know perl. And awk really sucks. Once I had to replace a perl one-liner with an awk script of ~30 lines for portability.
P.S. I never use awk just for print $1 as many do. It's an overkill.
Brand does not matter. You will likely get in trouble with any new laptop model. Install the latest kernel, and probably most of them will be gone. But some can be fixed only after a year or so.
My Dell with preinstalled Ubuntu had a fingerprint scanner not working, wifi chip losing connection and disabled "subwoofer" (lol). After a year or two of upgrading a distro everything works (well, I mapped subwoofer output in config and idk if this still needed or not).
I'm sorry for your loss, however the egrep deprecation is a fact. Of course you can continue using it as a veteran, but it is not correct to recommend this to beginners.
Perl has introduced powerful backtracking regexes that were widely adopted. However they can be damn slow in some cases, that's why RE2 refused backtracking while using some perl-like elements. Both basic and extended POSIX regexes are also non-backtracking because they are older than perl.
GNU grep, the most widespread implementation, does not include egrep, fgrep and rgrep for years. Distributions (not all, but many) provide shell scripts that simply run grep with corresponding option for backward compatibility. You can learn this from official documentation.
Also, my scripts are not full of bashisms, gnuisms, linuxisms and other -isms, I try to keep them portable unless it is really necessary to use some unportable command or syntax.
Try testdisk. It can copy files from damaged filesystem without touching it. But only if you are lucky enough and the filesystem is not so heavily damaged that testdisk will be unable to find it.
The only one you really need to care about (especially under Linux) is PCRE,
Well, no. sed, grep, awk, vi etc. use POSIX regexes. GNU implementations also provide perl compatible mode via an unportable option. In modern programming languages like go and rust standard regex engines are compatible to RE2 - relatively new dialect developed in Google that is not described in the Friedl's book (you may think of it as an extension of extended POSIX dialect). Even raku has its own dialect incompatible to perl as well as other ones.
Nowadays it is common to move away from perl-like engines, however they are still widely used in PCRE based software and software written in python, JS etc.
It is a great book, although a bit outdated. In particular, nowadays egrep is not recommended to use. grep -E is a more portable synonim.
Some notes on you script:
You don't need to escape slashes in grep regex. In the sed s/// command better use another character like s### so you also can leave slashes unescaped.
You usually don't need to pipe grep and sed, sed -n with regex address and explicit printing command gives the same result as grep.
You could omit leading slash in your egrep regex, so you won't need to remove it later.
So I would do the same with
tar -tzvf file.tar.gz | sed -En '/\.(mp4|mkv)$/{s#^.*/##; s#\.\[.*##; s#[^a-zA-Z0-9()&-]# #g; s/ +/ /g; p}'
Thank you, I forgot this.