Can I make "From this exectuable" optional?

[UnconnectedBedna]

I use yt-dlp and sometimes it runs python from the command line and sometimes it runs it "from this executable" and removes /usr/bin/python & the path to yt-dlp in "from this command line".
I don't know why, it seems completely random, so now I need two rules to make it work. (it started happening yesterday, previously it always ran "from this executable")

I tried to make "run from this executable" optional by making it a non-capturing group in regex: (the executable requires the exact python version here, ie currently python3.14 so I opted to use .* so it won't break when python version changes)

^(?:\/usr\/bin\/python.*)?$

And the command line like this: (python on command line is ran via "python" not the exact version)

^(?:\/usr\/bin\/python \/usr\/bin\/)?yt-dlp --no-windows-filenames --embed-chapters(?:\s--cookies-from-browser firefox)? -p \/path\/to\/download -o %\(title\)s\.%\(ext\)s.*$

I run the command line like this: (I actually have an alias, but this is what is being ran in the terminal)

yt-dlp --no-windows-filenames --embed-chapters -P /path/to/download -o "%(title)s.%(ext)s" "https://www.youtube/yadayadayada"

OR

yt-dlp --no-windows-filenames --embed-chapters --cookies-from-browser firefox -P /path/to/download -o "%(title)s.%(ext)s" "https://www.youtube/yadayadayada"

The quotes around "%(title)s.%(ext)s" gets removed, but I guess that could be the shell (or the alias) not opensnitch, but using without them in opensnitch works so... 🤷

I know using non-capturing groups with regex works with the command line because the optional "--cookies-from-browser" works, but it seems to not work with the executable, or is it the anchoring and ending (^ & $)? I tried removing them but it didn't work without them either.
Is there a way to make this into one rule where if the executable is not called with "from this executable" it can be empty?

Thank you in advance!

[UnconnectedBedna]

I guess the answer is no then and I need two rules, this changes randomly and I have no idea why, I updated yt-dlp yesterday so it must come from there, not opensnitch. The same thing happens with deluge so I need two rules there too.
Ie, sometimes it uses "from this executable" (with python version) and sometimes bakes python into the command line and then also includes the path to yt-dlp, so I need rules for both.
Or now that I think about it, maybe I can just remove "from this executable" and have a non-capturing group in "from this command line".

But you are wrong about non-capturing groups (the way it is written in OP) not working with opensnitch, because I CAN use it with or without the --cookies-from-browser with the regex I use in "from this command line". Ie both are accepted by the rule.

Good catch about -p & -P, I also just noticed this about an hour ago but forgot to edit my post here.
What is odd though is that both -p & -P works inside "from this command line", that was a typo in the regex on my part, it should obv be capital -P (lower -p is password), but the rule still accepted it even when it was a lower -p! I have had it set to lower -p in the regex for months! 😯
In regex, that should not work...
Bug?

Thank you for the clarification about the quotes, I figured it had something to do with the shell. 😸

[mohammadrezwankhan]

You're right, and I need to correct my earlier answer: OpenSnitch's Go toolchain does support non-capturing groups such as (?:...). My claim that the daemon rejects them was wrong—sorry about that. Your working rule is consistent with both OpenSnitch v1.8.0 and Go 1.23/1.24.

Your last idea is also the one-rule solution: uncheck “From this executable”, keep “From this command line” checked, and make the Python launcher/path prefix optional. For the forms described here, this is a compact version:

^(?:(?:/usr/bin/)?python[0-9.]* +)?(?:/usr/bin/)?yt-dlp +--no-windows-filenames +--embed-chapters(?: +--cookies-from-browser +firefox)? +-P +/path/to/download +-o +%\(title\)s\.%\(ext\)s +.+$

That accepts all of these command prefixes:

yt-dlp ...
/usr/bin/yt-dlp ...
python /usr/bin/yt-dlp ...
/usr/bin/python3.14 /usr/bin/yt-dlp ...

so you do not need two rules if a command-only allow rule has the security scope you want.

The lowercase -p matching uppercase -P is not a regexp bug. OpenSnitch rules are case-insensitive by default: for a regexp rule, the daemon lowercases the stored pattern before compiling it and lowercases the observed command before matching. Therefore -p and -P compare as the same text. The editor's Case-sensitive checkbox enables exact-case matching; with it checked, use only -P and lowercase -p will stop matching. Without it, [Pp] is unnecessary.

If you want to keep an executable restriction as well, one path regexp can enumerate the actual paths shown in Events, but that independently accepts every allowed path with every allowed command shape. If you need the two path/command pairs to remain strictly correlated, use two rules; OpenSnitch combines fields within one rule with AND, not an OR of pairs.

Thanks for challenging the non-capturing-group point—the correction matters here.

[UnconnectedBedna]

May I ask, why is not \ (escape) required before / for paths in opensnitch regex?

Edit, for clarity: for yt-dlp, only following is necessary:

yt-dlp ...
/usr/bin/python /usr/bin/yt-dlp ...

So following is enough: (as in OP, but removed the backslashes)

^(?:/usr/bin/python /usr/bin/)?yt-dlp --no-windows-filenames --embed-chapters(?:\s--cookies-from-browser firefox)? -P /path/to/download -o %\(title\)s\.%\(ext\)s.*$