3

In the tutorials/manuals, I often see numbers like this. Is it necessary? If so, specific numbers necessary?

To make the setting persistent across reboot, one can use a udev rule:

/etc/udev/rules.d/69-hdparm.rules

https://wiki.archlinux.org/title/hdparm

Damn Vegetables
  • 1,377

1 Answers1

5

From man udev in Rules Files section:

RULES FILES

The udev rules are read from the files located in the system rules directories /usr/lib/udev/rules.d and /usr/local/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d. All rules files are collectively sorted and processed in lexical order, regardless of the directories in which they live.

So the short answer is Yes, specially if you do care about the order in which the udev rules are processed.

Edgar Magallon
  • 4,820
  • 3
    I'd add in this good answer (regarding last question in OP) that since only lexical order is important, no specific number is required for a given rule. The associated filename only needs to start with a sequence of chars that will rank the rule as desired amongst the others. Numerals are just an handy way to manage the order. The latest rule to be executed is often named 99-whatever but could also well be named zz-whatever instead. – MC68020 Jan 07 '23 at 09:03
  • 1
    I implement a similar pattern to this for sourcing config/bash files which follows this quite common pattern.

    for f in $(find ~/.config/xxx/conf.d/ -maxdepth 1 -type f| sort); do source $f; done

     – Brad Jan 07 '23 at 15:25
  • 2
    @MC68020 Very good point! I forgot to address that info in my answer but yours is actually good and complements my answer in a good way! Thanks – Edgar Magallon Jan 07 '23 at 15:42
  • @Brad that's a good way to know the order in which the files are processed. Although udev rules cannot be sourced (they are not shell scripts) that's a good way to get the actual order and it's important for scripts which follows this rules of sorting. AFAIK the init deamon (when you (re)start,stop a service) are processed using something like this method. – Edgar Magallon Jan 07 '23 at 15:48
  • 1
    @Brad btw using zsh you could show the files in a sorted way so you can avoid the use of sort. (Untested) this might works source "$(find ~/.config/xxx/conf.d/ -maxdepth 1 -type f| sort)" – Edgar Magallon Jan 07 '23 at 16:01
  • 1
    @EdgarMagallon - indeed -- I wasn't suggesting to source the udev files, just giving a similar example. This pattern is used so often in unix. My use case was that I decided to break out my complex and overly long .zshrc into sub-files to make them more manageable. I use this method to source the sub rc files from the main rc file. – Brad Jan 07 '23 at 16:01
  • 1
    @EdgarMagallon, no source file1 file2 sources file1 with file2 in $1. You want for f (~/.config/xxx/conf.d/*(N.)) . $f. Using find that way doesn't make sense – Stéphane Chazelas Jan 07 '23 at 20:08
  • @StéphaneChazelas oh, thanks! I haven't been able to test that so I was not sure it it'd work or not. That code is for zsh, isn't that? For bash, is there a way to use glob qualifiers? (For sorting data like zsh does) – Edgar Magallon Jan 07 '23 at 20:32
  • 1
    @EdgarMagallon, glob qualifiers are zsh-only. But here, the glob qualifiers are N for nullglob and . as the equivalent of -type f. Sorting is lexical by default like in every shell, though you could also use the n glob qualifier for numeric sorting (for 12_foo.conf to come after 2_bar.conf for instance) – Stéphane Chazelas Jan 07 '23 at 21:20
  • @StéphaneChazelas thanks so much! I was wrong and also I was thinking N was used for sorting. Thanks for the clarification. – Edgar Magallon Jan 08 '23 at 04:37