My theory is that when you glob with wildcard * the order of things found is in alphabetical order thus the numbers will preserve execution order and provide sufficient gap to insert custom extras.
Your initial take on how these rules should be specified isn’t entirely wrong, but there is more to it than just that.
By specifying the name with a number prepending their actual name, distros, packagers and software providers are able to assess that there won’t be any conflicts.
Think of it this way:
I maintain a package for Debian GNU/Linux that creates a vhost in Apache for the program being installed. Let’s call the program netdata.
But, at the same time I’m providing a vhost for Apache with the package (/etc/apache2/sites-available/netdata.conf), there is another package in Debian’s repositories called proxywatch which calls it’s vhost file netdata.conf.
You can quickly see what I’m getting at.
By prepending it with a number of my choice - as far as I know there’s no rule to the number prepending the files - I can avoid such conflicts.
I assume others with more experience might be able to gather something from memory to explain this better.
From man udev on Fedora 34 (presumably the same on Debian):
Blockquote
The udev rules are read from the files located in the system rules directories … All rules files are collectively sorted and processed in lexical order, regardless of the directories in which they live.
So, yes, it is a way to explicitly mark processing order & priorities in case there are multiple definitions
Thank you, this is a good explanation.
Avoiding conflicts sounds like a good idea.
I not use it as I come more from a Arch linux land.
Now I wonder if I can count on the base languages (sh, python, awk, bash…) to expand/executes wildards in the lexical order as @blooper98 pointed out from udev manpage
Actually, there is. These rules are processed in numerical order and therefore the numbering needs to reflect the logic of processing each script in relation to its dependencies. Take networking as example: before requesting a DHCP address, the kernel must have established a physical link to the router. Thus, the script providing said link will have a lower number then the one requesting an IP address. Conversely, on shutdown (no matter whether you want to power off the machine or simply reboot), first the IP address needs to be released to the server, and only after that can the link be stopped. So on shutdown, scripts are processed in reverse-order instead.
My theory is that when you glob with wildcard * the order of things found is in alphabetical order thus the numbers will preserve execution order and provide sufficient gap to insert custom extras.
Your initial take on how these rules should be specified isn’t entirely wrong, but there is more to it than just that.
I meant more as of a rule such as 1 belongs to initialiazing USB devices, 2 to checking for GPUs and dealing with them etc. From the Debian documentation I could gather (granted the time I took to do so was near zero) there is no such standardized thing.
By the way, if I come off as passive aggressive, it’s just the way I interact with people. I do not mean any harm.
I created some custom PowerShell bootstrapping with this same naming convention so that the separate scripts could be programmatically executed in order regardless of additional script being added or what the actual scripts names were.