Talk:Everything is a file

"simple streams of bytes"

documents, directories, hard-drives, modems, keyboards, printers and even some inter-process and network communications are simple streams of bytes

No, they are not:

• directories cannot be read(), only readdir()-ed
• server sockets of a connected type cannot be read(), only accept()-ed
• UNIX sockets can transmit additional typed data, like fd
• a packet socket is not a stream of bytes but a stream of packets

Etc.

The only universal function that I can think of is fstat. --WPcorrector (talk) 14:04, 22 January 2014 (UTC)

Indeed

Yep, things that are accessible to the machine out there in the universe (which may or may not include the rather simple database that appears as a tree with named links and (randomly accessible) byte arrays as leaves which we call today the "filesystem") cannot all be byte streams. One would at least demand "streams of abstract datatypes" as we handle these days in "functional stream processing" at the language level. There is a T101 in your kitchen (talk) 11:13, 2 January 2024 (UTC)

What's about pthread ?

and semaphores - they also are not files. select and poll don't work on them. — Preceding unsigned comment added by 195.238.92.177 (talk) 13:20, 29 April 2014 (UTC)

Origin of the phrase "Everything is a File"

The writings of the original UNIX people are well-scrutinized yet there is no sign of them having written this phrase ever. I think the phrase is not authentic. The article is self-defeating in that it states "some IPC" is a file, meaning "not everything is a file as some IPC is not. The phrase is used as a joke in at least one presentation.

I was able to locate a 1990 conference paper that used the phrase: Clement Szyperski (ETH Zurich) There is “sex appeal” in UNIX’s “everything is a file” approach. The author uses the phrase in quotes as if it's not a literal expression. Can anyone find an older example? (talk) 23:02, 27 November 2022 (UTC)

Citation from Brian Kernighan's UNIX - A History and a Memoir

In , the phrase 'everything is a file' is not found, but several passages shed light on the related idea that:

• A file should be accessible to processes as an uninterpreted byte stream (or byte array) with no additional interpretation, typing or restriction by the operating system or the filesystem implementation.
• Resources like network interfaces, terminals, pipes etc. can be given names in a unified name space simply by listing them as entries in the hierarchical file system. However, read or write operations on such entries may not make sense. The filesystems entries /sys and /proc on Linux are good examples. Reading file /proc/1062/status dumps status of process 1062 as text (which can then be further analyzed ... as text), but writing to that file makes no sense.

On page 76:

Before Multics, most operating systems provided at best complicated and irregular file systems for storing information. The Multics file system was much more general, regular and powerful than other file systems of the time, but it was correspondingly complex. The Unix file system that Ken developed profited from Multics, but was significantly simpler. Its clean, elegant design has over the years become widely used and emulated. A Unix file is simply a sequence of bytes. Any structure or organization of the contents of a file is determined only by the programs that process it; the file system itself doesn’t care what’s in a file. That means that any program can read or write any file. This idea seems obvious in retrospect, but it was not always appreciated in earlier systems, which sometimes imposed arbitrary restrictions on the format of information in files and how it could be processed by programs. Doug McIlroy describes one example:

Typically source code was a distinguished type, different from data. Compilers could read source, compiled programs could read and write ‘data.’ Thus the creation and inspection of Fortran programs was often walled off from the creation and inspection of other files, with completely different ways to edit and print them. This ruled out the use of programs to generate (or even simply copy) Fortran programs.

Unix made no such distinctions: any program could process any file. If applying a program to a file doesn’t make sense—for example, trying to compile a Fortran source file as if it were C—that doesn’t have anything to do with the operating system.

On page 78:

Another Unix innovation was to have peripheral devices like disks, terminals, and others appear as files in the file system; disks are the “demountable volumes” mentioned in the list of features. The same system calls are used to access devices as are used to access files, so the same code can manipulate files and devices. Of course it isn’t that simple, since real devices have weird properties that must be handled, so there are other system calls for dealing with the idiosyncrasies, especially of terminals. This part of the system was not pretty.

On page 127:

One of the major simplifications of the Unix file system was its uniform treatment of files as sequences of uninterpreted bytes. There were no records, no required or prohibited characters, and no internal structure imposed by the file system—just bytes. There was a similar simplification in the way that most Unix programs handled textual data. Text files were just sequences of bytes that happened to be characters in ASCII (...)

On page 149:

Ken Thompson spent a sabbatical year at Berkeley in 1975 and 1976, where he taught courses on operating systems. Bill Joy, a grad student at the time, modified the local version of Unix, and added some programs of his own, including the vi text editor, which is still one of the most popular Unix editors, and the C shell csh. Bill later designed the TCP/IP networking interface for Unix that is still used today. His socket interface made it possible to read and write network connections with the same read and write system calls as were used for file and device I/O, so it was easy to add networking functionality.

On page 175:

Plan 9 the operating system was in part an attempt to take the good ideas in Unix and push them further. For example, in Unix, devices were files in the file system. In Plan 9, many more data sources and sinks were files as well, including processes, network connections, window-system screens and shell environments. Plan 9 also aimed for portability right from the beginning, with a single source that could be compiled for any supported architecture. Another outstanding feature of Plan 9 was its support for distributed systems. Processes and files on unrelated systems with different architectures could work together exactly as if they were in the same system.

There is a T101 in your kitchen (talk) 12:09, 2 January 2024 (UTC)

References

Plan 9 should be mentioned and extreme examples

One of the most extreme examples of this policy and where many things mentioned in this article originated (e.g., `/proc`) was Plan 9 operating system, it would be worthy to emphasize its role.

Also, some other extreme examples of this philosophy could be mentioned, e.g.:

• ii IRC FIFO-based client or its predecessor Plan 9 [sic] jacc Jabber FIFO-based client.

Ceplm (talk) 18:34, 15 July 2024 (UTC)