It would seem that if a file does 'everything', then it's not in fact doing 'one thing'.
Sources:
How does 'everything is a file' not contradict 'do one thing and do it well'?
Not only there is no contradiction—both go the same way.
“Do one thing and do it well” encourages composition over monolith. For instance, instead of having one huge application that makes it possible to create videos and also encode them and handle all sort of video devices such as video cameras, one could have a GUI for creating videos, and this GUI will rely on a separate program that deals exclusively with video encoding, and a separate program that handles devices and presents a video camera as a stream—in other words, a file.
The benefits of such an approach:
Programs are smaller, and therefore easier to maintain.
A user may only be interested in video encoding. No need to install the whole monolith just to do that.
Parts of the system can easily be swapped, and alternatives can be created more easily than when trying to create the whole monolith.
“Everything is a file” is a convenient way to achieve “do one thing and do it well.” Think of it as a standard.
Consider electricity at home. In your country, there is very likely a standard for wall sockets. Where there is a socket, you can plug in your PC, or a phone charger, or a desk lamp, or a vacuum cleaner.
Does the fact that one socket supports all those appliances mean that it's doing too many things? Well, not really. It does one and one only thing: it powers stuff you plug in to it. If there were separate plugs for vacuum cleaners (preferably each manufacturer would have its own “standard”) and other ones for your PC (Dell PC plugs won't fit in sockets designed for HP!) and different ones for chargers, and then there would be ones for CFL and ones for Osram LEDs, and ones for Philips LEDs... each socket won't do less compared to a standardized one. It would have the exact same role.
Same here. A file is just a standard by which components of a system may interoperate.
interface File, and there would be a whole lot of extends File. I'd call that "everything is a file"
Everything isn't a file. Everything exposes an interface that works as if it was a file.
So all the bits "do one thing well" but they all can be used the same way. A bit like all the tools in your tool box having handles that work with human hands, even though the business end is different.
Because Unix Philosophy is more like guidelines than actual rules. I think you are correct to see the contradiction. Both rules, put into absolutes would conflict.
A file stream is a pretty bad abstraction for a network socket, but it allows programs made for reading normal files to "just work" on network sockets ("Everything is a file" wins over "Do one thing well"). Admittedly it works well enough in most cases. For an OS that took "Everything is a file" even futher than Linux, check out Plan 9
For an opposite example, "SQLite" exposes its API as an internal library calls, not as some kind of virtual file system. ("Do one thing well" wins over "Everything is a file"). That is because a fully-capable SQlite virtual FS would be insane, although there are limited variations such as sqlitefs.
The principle that "everything is a file" is an abstraction that shields programs from specific hardware. This abstraction is the very thing that permits programs to focus on their job. No matter where the data comes from — a "real" file on disk, output from another program, from the terminal, the serial bus, or from a network connection: The program is shielded from it. In its simplest form it can simply read a byte stream from stdin and write the result to stdout, i.e., use regular file descriptors for its data that are already open and ready to use. It does not have to know anything about anything except the data logic. The result is a tool that is highly portable across a universe of devices: Your toaster, an IBM mainframe, some AWS instance or your smartphone. You don't have to change a single line of code. The power and benefit of this concept is immeasurable.
In a different world where all the data sources and -destinations needed to be treated specifically, a large portion of any utility like grep, cat, sed etc. would have to be concerned with operating system APIs and periphery handling unrelated to their actual task.1
The perspective of the operating system whose job it is to give user space programs access to the periphery is also interesting: Even though it must do a myriad of jobs and must often have detailed hardware knowledge it manages to make it look like one job, which is exactly what makes life so easy for the user space programs.
1 Actual reality, of course, is a bit messier: Mostly for convenience and improved usability, many programs in fact do distinguish between different data sources or destinations. For example, many programs are able to open named files or behave differently when they detect that their input and output is a terminal (which in turn often creates problems e.g. in emulations!).
This is a false dichotomy. There are following options:
File is an interface (one of) of an general purpose operating system that establishes a bridge between drivers (filesystems, IO devices, network) and user space programs (editors, messengers, music players).
It is a limited and arguably not very universal interface. Unix saying "everything is a file" is a lie, in a sense that operations that it allows to do over a file object are by no means file-like. Unix can send datagrams over file, listen for them, execute a broad set of esoteric commands like "write data and wait for an hardware interrupt".
Windows separates un-file-like operations better, by providing other types of OS handles (sockets, pipes, ports). It still gives some file-like operations to those though.
There is indeed an inherent contradiction between an attempt to implement generic interface for disparate entities and make it work well for a single task.
The current situation (Unix adding strange operations over files and Windows supplying some file-like operations on non-file devices) is the result of a compromise. Too narrow of interface would shift complexity from device driver to user space programs. Too wide interface would shift the complexity the other way. Imbalance would cause one or the other to die out. General purpose OS is tasked with balancing things out, hence suboptimal, but universal solutions.
To really understand how the conflict is resolved, one has to look into real-time or specialized or embedded OS implementations - there compromises are resolved in a different way because no priority is given to broad application of an OS.
