sjohannes

It doesn't launch the new binary at all. When the current process wants to create a new process, instead of doing fork+exec (which launches the new binary and wreaks havoc because versions now don't match), it simply tells the ForkServer (a different process running the old binary) to fork (split) itself.

Chromium also does this; they call their equivalent to ForkServer the zygote process and this article explains it really well.

The article mentions "GNU getopt" but as far as I know GNU doesn't have a getopt utility; the version on most Linux OSes comes from util-linux. (Perhaps the author is confusing it with the C function with the same name.)

Note that other getopt implementations have different features and some are simply broken. For example, BSD getopt doesn't support long options and comes with this known bug:

Arguments containing whitespace or embedded shell metacharacters generally will not survive intact; this looks easy to fix but isn't.

For cross-platform scripts it's probably best to use the getopts shell builtin instead, the downside being it only supports fairly basic (POSIX) syntax even on Bash.

All external links from news.itsfoss.com articles have that ref parameter added. For example, see the links in this article about the Danish ministry that is switching to LibreOffice.

Edit: This is apparently something that the CMS they use, Ghost, does by default.

They're switching their main repository from Mercurial to Git. Mozilla started using Mercurial before Git became de facto standard, but I imagine these days learning Mercurial is seen as an unnecessary obstacle for new contributors, hence the current switch.

As for why GitHub specifically, it's because that's where the rest of Mozilla's projects already are. They have been using GitHub for a long time (14 years or more), with thousands of repositories there. It's why Rust and Servo are on GitHub, for example.

Edit: See https://glandium.org/blog/?p=4346 for more thorough/accurate info.

I don't think that works, because the command substitution in "$(…).txt" runs immediately in the current shell.

Aside from that, find -exec doesn't use a shell to run its command, which means $(…) won't work without an explicit sh call.

I believe the right command in this style that will work is:

find /my/mp3dir -type f -iname '*.mp3' -exec sh -c \
  'test -f "${0%.mp3}.txt" && mp3splt -A "${0%.mp3}.txt" "$0"' \
  '{}' ';'

However, I would recommend the for f in *.mp3-style solution instead, as to me it's more readable. (The Bash/Zsh recursive glob (**) syntax can be used if subdirectories are involved.)