I think you see killall in how-to's because by default it requires the precise process name, whereas pkill does basic pattern matching. Thus, killall is safer for users to blindly copy and paste.
Pkill and killall both have distinguishing options. Killall has a flag to match by process age, pkill has a flag to only kill processes on a given tty. Etcetera ad nauseum. Neither is better, they just have different specialties.
I see from their man pages that killall comes from the psmisc package, which has several process managing utilities, but notably doesn't contain ps. It's the procps package that has ps, top, kill, and pkill (among others). I'd wager procps didn't originally have pkill, so psmisc scratched an itch and came up with killall.
The pkill/pgrep man page says they were introduced in Solaris 7. As you mention, jgbelacqua, Solaris's killall was not the utility psmisc provides, thus Solaris probably only had the procps package. Someone wanted a pattern matching process tool, thus pkill and pgrep. Whether it was developed by the procps dev or added in afterwards, I don't know. Regardless, it made it in and became part of *nixes everywhere.
More sources:
Whether they should or shouldn't both exist is perhaps a debating point.
However - they are absolutely identical.
From the man page of apt-get
--purge
Use purge instead of remove for anything that would be removed. An
asterisk ("*") will be displayed next to packages which are
scheduled to be purged. remove --purge is equivalent to the purge
command. Configuration Item: APT::Get::Purge.
They key part is --purge is equivalent to the purge command
As to why - I would surmise this is historical -
apt-get --purge remove came before apt-get purge
Looking at the old apt documentation it make reference to the older version of the command. The newer documentation gives the aptitude & apt-get purge example.
For the sake of consistency - its a good idea to not remove old interfaces - if you have an old script - it will still work today because the interface commands still exist.
Mind you that doesnt stop Gnome from deprecating api's - but that's another story...
Best Answer
That's not unusual. Authors typically pick the simplest command name they think of, so if two people write a command to rename files, it's likely they'll both name it
rename. That's one of the reasons behind the Debian Alternatives system - it allows packages providing similarly-named commands to coexist, and for one package to replace another. For example, there are multiple AWK implementations -mawk,original-awk,gawk(though they all refer to themselves as awk). With the alternatives system, you can install them all at the same time, and conveniently switch between any of them as the defaultawk.In this specific case,
prenamecomes from the Perl source code. The Debian package maintainers originally hadrenamebe the Perl one, then switched to the alternatives system, to accommodate therenamefromutil-linux. Then somebody wrote an improved version of Perl'srenamein the File-Rename Perl module, which was then added as another alternative. But that's not even the only Perl module for renaming files.See Debian bug #735134 for how this situation evolved. Debian maintainers generally prefer going at least one release when doing something drastic, like replacing a working command with another.
prenamewas kept around for jessie, and has now been removed for buster. In addition, it looks likerenamewill no longer be under the alternatives system, sincerename.ulis too incompatible.renamewill be justfile-rename.Since Ubuntu generally picks up packaging changes from Debian, what happens to
renamein Debian will be picked up by Ubuntu sooner or later, probably in 18.04. It seems to be too late for 17.10.Fundamentally, both
prenameandfile-renamerun Perl expressions to rename files.file-renameis just actively maintained and supports more options.renamefromutil-linuxworks entirely differently, has its own rules for patterns.