The real WTF is that APT spawns an external process to check disk usage, instead of invoking statvfs() on its own.
Some cases are less clear-cut, however. For example, the Debian 'nodejs' package installs node.js binary as /usr/bin/nodejs and not /usr/bin/node because it conflicts with another package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#108
And let's not forget rename(1) from util-linux versus the Perl rename(1)...
That doesn't make it much better though. Parsing the output of df (with a useless tail -1) is kind of awful when you can use something like stat -f -c %a.
I agree with your comment about it being functional. But wouldn't removing tail from the pipe remove complexity and speed up the processing(Arguably, most likely only by a small fraction)
On the node thing: that decision has recently been reversed by the technical committee, effective in the next release (it is in unstable now). See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862051 - nodejs will now simply be 'node'.
Using aliases in `~/.bashrc` rather than putting scripts or symlinks in $PATH is a good mean to avoid those kind of problems, provided bashrc includes code to quit if ran in non-interactive mode (default at least on ubuntu).
Many use aliases only to specify default command parameters, but it works just as well to provide an execution path, like, in this case:
alias df=/home/my_user/games/dwarf_fortress/df
It would only be executed in interactive sessions, this way, which should guard well enough against system code interpreting it.
Of course, this still means user can't use system's `df` easily, but I guess they don't use it anyway since they did not realize the problem until that upgrade.
My point was more to show a way this particular user could have achieved the same result without their problem.
Plus, we can't expect users to know all the system tools, this is a good way to isolate "user space" from "system space", so I guess taking the habit to use aliases rather than putting things in `/usr/local/bin/` makes sense by itself (except when we want indeed to override an executable provided by system, or we want indeed to provide a new system tool).
Hate it when I'm starting a newly written python script, and have forgotten the hashbang. For some reason my mouse cursor turns into a cross, and the script does nothing!
Always takes me a couple of seconds to realize what's going on...
When I did my first few programming courses we were using C and on Windows, and using system("pause"); was our way of keeping cmd from closing. So as a joke over the years I've made a pause script for Linux in Python, Perl and even bash just so I can make such code valid.
But putting a whole game in place of a standard Linux util sounds like awesome menace, reminds me of the sl command (steam locomotive) which you can install on Debian (and maybe other distros?) for those who may typo ls they'll get a fun surprise :)
It was and still is, the name is _getch() from <conio.h>
However, I can see how for a beginner programmer system("pause"); is more intuitive than printf/_getch() combo. Especially if said programmer is already familiar with windows shell and its commands.
Just wait till they release "Ground Control Center" (gcc) :-) For a long time there were two things called 'git' and installing the 'wrong' one invariably led to similar hijinks.
On Unix/Linux, there is very little stopping the superuser from introducing new and inventive kinds of breakage, such as in this case. This one is just a little more amusing than most. But seriously, if root wants to install a new command called df and have it higher up in the PATH than the standard utility, why should the OS argue?
But actually, it would be cool to have some kind of warning, like a POSIX linter that warns the user something broke the standard, and they can decide to ignore it and never hear about it again. I'm not a big fan of linters, usually, but it would make sense for end users tweaking their system.
It's mostly about all necessary libraries being available for the same architecture as the binary.
This means either having separate 32bit libraries (typical for closed source applications shipping together with their libraries) or having multiarch libraries (as modern linux distros do).
Some cases are less clear-cut, however. For example, the Debian 'nodejs' package installs node.js binary as /usr/bin/nodejs and not /usr/bin/node because it conflicts with another package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#108
And let's not forget rename(1) from util-linux versus the Perl rename(1)...