Computing desk
< January 16	<< Dec \| January \| Feb >>	January 18 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 17[edit]

Everything is a file made of files[edit]

Hi,

Are there any operating systems or command line interfaces who go farther than the usual everything is a file, e.g. by considering that a line in a file, or a character in a line, is similar to a file in a directory?: for instance, mv foo/5/1 bar would delete the first character of the fifth line of file foo and would create file bar containing this character.

Thanks. Apokrif (talk) 23:01, 17 January 2020 (UTC)[reply]

Apokrif, None, as far as I am aware. MoonyTheDwarf (Braden N.) (talk) 23:03, 17 January 2020 (UTC)[reply]

Plan 9 from Bell Labs, later Inferno, is perhaps the OS which took this Unix-derived "everything is a file" concept the furthest.

That said, you don't seem to be treating files as files, or even directories as being a specialised sort of file, but rather trying to handle files as if they were directories. That's the opposite of "everything is a file".

As I can't think why it's useful to do this (we already have plenty of tools to chop up files, and they're better than mis-using the directory tools on the same objects), so I can't offhand think of a reason to or example of doing this. Andy Dingley (talk) 23:18, 17 January 2020 (UTC)[reply]

@Andy Dingley: That's not completely opposite if you consider a directory being a file, too.

--CiaPan (talk) 13:45, 19 January 2020 (UTC)[reply]

@Apokrif: Just like Andy Dingley above, I can't see a reason for implementing such trick. This is quite artificial to me and very limited. Some important questions, which came to my mind first:

how about handling line lengths - how would one determine a copy destination position to perform appending to a line?
how about inserting items, which involves both moving existing items (arbitrary number of them) to farther positions and overwriting released positions with new data – what syntax would be able to define such task?
is it worth implementing at all? most files are not plain text files – they are used to store programs, music, images, movies, countless structured data types, multiple databases among them; also different system data, like file management system internal data (directories); even textual data are nowadays stored in structured files (whether MS Word .doc & .docx, OpenDocument formats or even just a Rich Text) – ALL of them must never be handled in a way you describe. And plain text files are well handled both by visual tools like notepads or vi, by command-line tools like ed and by stream editors like sed. So what's the reason to implement a trick, which is limited, difficult and useless?

--CiaPan (talk) 13:45, 19 January 2020 (UTC)[reply]

On early Macs, every file could also be a database that could potentially contain many other sub-files, in addition to its ordinary content. It was an interesting concept and had some handy uses, but never got momentum outside of Apple and was later depreciated and more-or-less removed from modern Mac OSes. 108.29.38.53 (talk) 20:13, 19 January 2020 (UTC)[reply]

@CiaPan: I'm not claiming it would be easy to implement such a system, but I was considered plain text (perhaps even with fixed line or record length) rather than binary files (although other formats could be managed by a description, available to the OS, of binary formats: e.g., the OS would itself wrap the new line of text into whatever binary sugar the MS-Word format needs before inserting it to the right place in a .doc file).

"visual tools like", "command-line tools like", "stream editors like" my point is to limit the numbers of tools needed: you would have to know only the OS, filesystem, or command-line interface, to handle (some actions on) files, without having to install or learn other software. Apokrif (talk) 14:31, 21 January 2020 (UTC)[reply]

I learned to program on Unix systems. I never ever heard "everything is a file." What we said was "everything is I/O." No matter what it was, it could be defind by input and output. That is how programming works. Everything is a function with defined input and output. Hardware uses drivers that define input and output. To this day, you can access input and output streams on everything or create a wrapper for an input/output stream for something that isn't truly an I/O device, like a section of a text file. I feel that calling everything a file is a dummied down version of calling everything I/O. 135.84.167.41 (talk) 17:53, 21 January 2020 (UTC)[reply]

Sounds more like you learned to program in C, as if the underlying OS reflected how C (and stdio) was structured. Which is fine, until you try to use another language and then find that even though you're on the same platform, everything is now different. Or even that you move your C program to a new OS, and then you find it doesn't work because the abstract representation of things which really are files is no longer the same, when you look at it through the wrong abstraction.

If you do this in Pascal, then it works. But that's because you only ever got an extremely narrow abstraction for what a "file" was, sacrificing expressiveness for portability. Andy Dingley (talk) 17:59, 21 January 2020 (UTC)[reply]

I actually started in assembly (everything is a register address) before going to C (everything is io). I've personally found that the background made it very easy to pick up languages as needed. The only one that was a bit of a struggle was M (or Mumps if you are using the licensed version). But, I rarely find anyone who agrees with me when I suggest teaching computer architecture and operating systems before teaching programming. So, I can't say that learning programming from assembly first would help anyone else. 135.84.167.41 (talk) 20:03, 21 January 2020 (UTC)[reply]

I certainly came across "everything is a file" in UNIX when transferring from OpenVMS. Consider the following file paths:

DUA0:[USERS.MARTIN.WIKI]SAMPLE.TXT - VMS
D:\Content list\Pictures\Armature.jpg - DOS/Windows
/home/martin/boats/LuluII - UNIX/Linux

Note that only *nix treats every part of the path as a file, other OSs will distinguish between disks, directories and files. Martin of Sheffield (talk) 09:53, 22 January 2020 (UTC)[reply]

Files often are treated as filesystems: loopback device, virtual file system#Single-file virtual file systems, archivemount etc. Here's an ancient text suggesting treating XML this way.—eric 19:37, 21 January 2020 (UTC)[reply]