Today has been fun, in an up-and-down and terrifying sort of way!
First the good news: I finally managed to build a pure Arch-based virtual machine with no slip-ups, mistakes or catastrophes. Installing Arch is never for the faint-hearted and I've done it lots of times in the past... but never done it 'quite right', with always something missing or not-quite-working! I accordingly long ago gave up hope of ever achieving something that seemed stable and functional. But that run of ducks was broken today! Hurrah. (And I've written up how I did it here).
The significance? It means I can test all my audio software on Arch for the first time -which it passes, so I've added Arch to the list of 'supported' distros on my software page.
At which point, I was cresting the wave of the ride... before plunging quickly into less enjoyable things!! Which is to say that it turns out that, alone of all the distros I've tested this stuff on, Arch turns out to have a program pre-installed called the Device Tree Compiler. I have no real idea what it does (I did look for about 3 minutes, but was generally none the wiser after than before), but whatever it does involves installing a binary called dtc in the /usr/bin folder. Which is a bit of a problem for someone whose Dizwell Tag Cleaner... also wants to install a script called dtc in the same folder!
In other words, having got Arch running, I found out that one of my scripts won't install on it properly, because of a name-clash with a pre-existing package. 🙁
Now, as it happens, the 'Dizwell Tag Cleaner' is not one of my more significant scripts: you run it once to clear out extraneous tags from your music files and then you probably never need to touch it again. It's not like the AMP music player, for exanple, which you might use dozens of times a day. So: the first thing to say is that this name-clash on a not-very-popular distro is probably no big deal. You could still run the Tag Cleaner by invoking it as "dtc.sh" rather than "dtc", for example.
But: the name of my script is a bit of a nod to the past. In years prior to about 2016, I worked as a DBA in the Oracle database field, and the domain name I ran dated back to the time I first started work at Oracle Australia (around 1999): dizwell.com. Hence everything I did got the 'dizwell' name attached to it -and thus, the tag cleaning script was a Dizwell Tag Cleaner. But in 2016, I retired, gave up Oracle databases, and ditched the dizwell.com domain name (I still own it, and if you type it in your URL address bar, it will still re-direct to this website). Since my main focus these days is music, I acquired the 'absolutelybaching' domain name and have used it for everything ever since.
All of which is by way of saying that a script called 'Dizwell Tag Cleaner' is a tad old-fashioned these days. If I were writing it now, I'd call it the 'Absolutely Baching Tag Cleaner', the script would therefore be called 'atc.sh', there wouldn't be a name-clash on Arch, and everyone (apart from Air Traffic Controllers, perhaps) would be happy.
Which is therefore why a new version of the Dizwell Tag Cleaner has been released... with a name change. Version 1.07 of what used to be DTC is now version 1.07 of ATC instead. The executable is atc.sh and the shortcut to it is plain 'atc'. No more 'dtc'. No more Dizwell.
My recently-created fetchall.sh bulk update/installation script has been adjusted accordingly. It now downloads 'atc.sh', creates a shortcut called 'atc' and deletes a script called 'dtc.sh' if it finds one. Naturally, it only deletes dtc.sh (i.e., my shell script, if it exists), not the 'dtc' executable that Arch seems to depend on.
I'd finally recommend running that fetchall.sh script to everyone that is running any of my software: in the past couple of days, testing all my scripts on all the distros I can, I've had to make tiny tweaks and corrections to all of the scripts. They really are tiny changes for the most part, that didn't (I feel) warrant a new version number. We're talking things like moving a line of code down below 50 others, rather than have it on top, for example: the code itself is much the same, but it's location within the script is different. That sort of thing was needed to stop various distros I hadn't previously tested on from throwing spurious errors, for example. So: small changes, but they mean all ten scripts are now slightly different from what you've probably got on your system, though the version numbers might be the same. Functionally, the differences are minor -but a quick run of fetchall.sh will bring everything into sync once more. This one-off divergence is a result of the testing-on-multiple-distros program I've recently concluded and won't happen again (I promise!)