bizdelnick

It seems you need to read the official documentation yourself.

I did. Debian man page, GNU grep manual.

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.

Yes, it could find partitions removed long time ago if filesystem headers were not overriden.

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.

Well, technically it is possible with regex dialect that has lookarounds, but it is overcomplicated. There's really no reason to do it.

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:

1. 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.

2. 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.

3. 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}'

CLI is conservative, GUI tends to change with each release. I have no time to search where is the menu item I need now or where is the menu itself.

I hope, mostly no. It is needed to operate various old equipment.

Many companies still use Windows XP, so...

How often do you think about crostini?