Reminded me of a major “data”/“AI” platform that stripped all empty files when deploying the code. Because of “security” you were not allowed to list files on the deployed instance, nor review the deployment pipeline code or logs (“it just a works/batteries included”).
The most brilliant way to screw all Python developers I’ve ever seen.
Later learnt that the docker container run the code as root, so basically you could destroy the platform from within. Good times.
Pretty cool. But as everyone is pointing out, empty files aren't that interesting. 31/137.
$ find . -name ".git" -prune -o -name "README.md" -prune -o -type f -print | wc -l
137
$ find . -name ".git" -prune -o -name "README.md" -prune -o -type f -empty -print | wc -l
31
Some of these files are very much nonstandard, even when the standard leaves no leeway (unlike HTML). E.g., every PDF standard requires an %%EOF, startxref offset, and an xref table (or an xref stream in the later versions), but this PDF file is missing those, among other oddities, like the page object missing a /Type and /MediaBox. Too bad the author doesn't specify which implementation these are supposed to work in.
There must be some interesting code golf stuff hidden in here, but it seems like it's mostly empty files.
For people who enjoy this sort of thing, vaguely related is this puzzle: https://dmd.3e.org/a-shell-puzzle/
Okay, but what about the largest possible files?
...I feel like completely empty files shouldn't be allowed. Like, I realize the Python interpreter won't error if you feed it an empty file, but how can you really say that empty file represents a Python script if there is no script there?
However, I can't put my finger on what the correct rule would be.
File size of -∞ is the smallest
The 42 byte transparent GIF saw ample use in web development a quarter century ago, when it was used to create pixel perfect <table> layouts. Some things have changed for the better.
https://x42.com/test/gifdot.shtml?abcdef