On Wed, Jan 29, 2020 at 08:42:20PM -0600, Peng Yu wrote:
So a one-line summary is
When the target can be delete, unlink and rm -f are the same;
otherwise, unlink will complain about the error and exit with 1, but
rm -f will do neither.
No, rm -f will also exit with 1 if the file exists bug can't be deleted.
From a user perspective (in the absence of bugs) there should be no
difference between the two commands except that unlink will fail if the
file doesn't exist and rm -f will succeed. By itself that's probably not
a reason to justify a new command if we were starting from scratch
without historic baggage. :)
Even much more recently than the days of manual directory creation, it's
been possible to get files that for one reason or another confound
the complicated logic in rm. You should generally be able to force rm to
remove the file anyway with -f, but in some cases there have been bugs
which made -f not work either. I don't think that can happen anymore,
but never say never. I suppose rm could be extended with a new
--just-try-to-unlink-and-tell-me-what-happened option to ensure that
you're always unlinking (and to fail with rm -f on nonexistent file),
but since unlink(1) is already defined it's simpler to just use that if
you don't need the convoluted rm semantics.
Historic note: before unlink was added to fileutils I remember using
rm -d force unlink on a particular recalcitrant file, and thinking that
was a ridiculous workaround. :) That shouldn't work anymore, either, but
it's an example of how there's a lot of version-depended logic and bug
fixes in rm, but unlink is always just going to unlink.
