I've mentioned that one of the practical issues with DKMS is that it's a giant Bash script and that Bash isn't the right language for large programs . I'm sure that these issues aren't new to the authors of DKMS , so an obvious question to ask is why did they chose to use Bash for DKMS. In fact you could ask this about a surprising number of relatively substantial programs on a typical Linux system. Dracut is 2,000 lines of Bash, for example. The authors of these programs are neither stupid nor crazy. Although I don't know their reasons, I can speculate.

For programs like DKMS and Dracut we can rule out broad portability, since they're already for Linux only. Portability is a likely issue for some large scripts on Linux systems that aren't strictly speaking Linux-only, such as the 12,000 lines of libtool . However, even for Linux only programs, people may care about avoiding additional dependencies and requirements. According to RPM on my Fedora 33 desktop, Dracut and DKMS each theoretically require only on a relatively small collection of core Linux programs and packages.

But I find myself believing that there's another reason for projects like DKMS and Dracut to stick to Bash, no matter if it's an awkward fit, and that's the desire to remain what you could call apolitical in their choice of language, which is to say avoiding having people argue with them about it. If DKMS or Dracut was written in Perl, Python, Ruby, or maybe even C++, there probably would be any number of people who'd be vocally unhappy with the choice and with the authors for making it. Unfortunately, I think that there are very few language environments on Linux that everyone considers acceptable and part of what they feel is the base system. In some ways Linux is quite conservative.

(I may be overly influenced from having been reading the Linux kernel mailing list during the time when there was a proposal to write a better kernel configuration system in Python. Some people were pretty unhappy at the choice of Python, although that was not the only problem with the proposal.)

Bash is not a particularly good language for writing a large program with significant logic that's potentially an important part of maintaining a Linux system. But it's a choice everyone will accept. They may think you're crazy, but they're probably not going to try to keep your program out of their Linux distribution because of what it's written in.

(An advantage of Bash is that I don't think it's changed all that much over time, so you don't have to worry about what version a particular Linux distribution has the way you do have to for Python or some of the other options. In my opinion this is overshadowed by its drawbacks for large programs.)

PS: This isn't an issue that BSD Unixes have, because their model of development means that a BSD can declare something part of the base system if they want to. Linux isn't coherent like this , so people are forced to either stick to the practical union of what distributions accept or start an argument to enlarge that de facto core set. Trying to do this can be contentious, as seen in the recent case of Python cryptography, Rust, and Gentoo .