You can do a lot with an empty file

Yesterday's post about "pipefail" also involved some systems which treated an empty file as a valid file. This turns out to be surprisingly common. I think people might be shocked at exactly how much you can get away with, and how many different things will accept such a beast.

One of the failure modes I used to see with certain package-based systems at a job with a large number of computers is that sometimes it would just fail to populate it with actual data. This might've been due to a reboot during the package install process, or maybe the packager got killed for some reason, but it meant all kinds of badness would happen.

In particular, I saw times where it would drop a file on the disk in the right place, with the right permissions (readable + executable) but totally empty! Then, later on, something or other would ask if the package was installed, and as far as the package database was concerned, it was. Also, then the cron job would try to run one of these binaries... and it wouldn't fail. Nope, it was perfectly happy running exactly nothing.

Yes, if you weren't already aware of this, an empty file that's executable will totally "run" to "completion" and will even yield an exitcode of 0. If you are checking that exitcode for success or failure, it's going to think everything is just fine.

No, really, look:

linux$ touch empty
linux$ chmod a+rx empty
linux$ ls -l empty
-rwxr-xr-x 1 rkroll rkroll 0 Apr  6 12:07 empty
linux$ ./empty
linux$ echo $?
0

Awesome, right? This works just fine on Macs as well. I don't have quite the assortment of shell accounts on other flavors of Unix that I did back in the '90s to test further, but I have to assume it'll probably work most of the time. It's probably something funny involving how the interpreter is spun up - looking for #! and that kind of stuff.

I mean, what would the error be, anyway?

Does this mean the smallest /bin/true is actually an empty file?