Why it makes sense for
false to ignore their arguments
It's standard when writing Unix command line programs to make them check their arguments and complain if the usage is incorrect. It's reasonably common to do this even for programs that don't take options or positional arguments. After all, if your command is supposed to take no arguments, it's really an error if someone runs it and gives it arguments.
(Not all scripts, programs, and so on actually check this, because you usually have to go at least a little bit out of your way to look at the argument count. But it's the kind of minor nit you might get code review comments about, or an issue report.)
false are an exception to this, in that they more or
less completely ignore any arguments given to them. Part of this
behavior is historical; the V7
extremely minimal, and when you're being minimal it's easiest to
not even look at the arguments. But beyond the history, I think
that this is perfectly sensible behavior for
because it makes them universal substitutes for other commands,
for when you want to null out a command so that it does nothing.
Want to make a command do nothing but always succeed? Simple: '
command command.real; ln -s /bin/true command'. Want to do the
same thing but have the command always fail? Use
true. Sure, you can do the same thing with shell scripts that
deliberately ignore the arguments and just do '
exit 0' or '
1', but this is a little bit simpler and matches the historical
(You can also do this in shell scripts as a way of creating a 'don't actually do anything' mode, but there are probably better patterns there.)
On that note, it's interesting to note that although GNU
false have command line options that will cause them to produce
output, there is no way to get them to return the wrong exit status.
And while they respond to
--version, they silently
ignore other options (as opposed to, say, reporting a syntax error).
(This entry was sparked by Zev Weiss's mention of
true in his
comment on this entry.)
false in V7
In V7 Unix,
true is an empty file and
false is a file that is
literally just '
exit 1'. Neither has a
#! line at the start of
the file, because that came in later. That
true is empty instead of '
exit 0' saves V7 a disk block, which
probably mattered back then.
Apt-get and its irritating lack of easy selective upgrades
One of my many irritations with
is that it doesn't easily allow you to only apply some of the pending
updates. Sure, often you want to apply all of the updates (at
least all of the unheld updates), but there
are any number of cases where you want to be more selective. Sometimes
you are in a rush and you want to apply only a few very urgent
updates. Sometimes you want to apply updates in a specific order,
updating some packages before others. Sometimes you want to apply
most updates but temporarily exclude some that you consider low
priority or disruptive.
With a package manager like
yum (or now
dnf) you can easily do
either of these. If you just want to exclude some packages, you do
that with '
--exclude'; if you only want to upgrade some packages,
you do that by supplying them as explicit arguments. And it's
harmless to be a bit broad in your explicit arguments, because
you're specifically only upgrading existing packages; you'll never
install new ones out of nowhere.
apt-get does not support this usage as far as I can see.
upgrade takes no package list and has no way of excluding some
packages; it is an all or nothing operation, where the only way you
have of being selective is to hold packages in advance in order to
block their upgrades. In order to upgrade packages selectively, you
must turn to '
apt-get install', probably with '
so that you don't accidentally install new packages. And as far as
I can tell this has no equivalent of yum's
--exclude, so there's
no easy way I can see of saying 'upgrade everything except the
apt-get install does at least support wildcards, or more exactly
POSIX regular expressions. I don't know why they decided to use
regular expressions instead of shell globbing, but it feels like a
very Debian decision, especially the detail that it defaults to
apt-get install --only-upgrade PKG ...' solves about half of the
problem (although clumsily) so I'm less disgruntled than I was at
the start of writing this entry, but it's still not particularly