I came up with this idea...

We have symbolic links in most OSes, which are a small file which points to another file which is evaluated as it's accessed.

Why not having some kind of "view" attribute for files which make the OS to execute the file through the usual means (executable code or script specifying the scripting host with #! in the first line), then make it as if the results of this command are the contents of the file? (This view would be read-only, of course.)

When a process open()s or CreateFile()s a view, the OS executes the command and passes the process the results (lazily evaluated, keeping the command running unless it reaches EOF). If another process concurrently opens the file, the command is executed again in case the results could change, but they should be kept consistent for every handle (in a memory buffer, to allow for backwards random access).

To edit the view, one would just unset the view attribute and edit it as a regular file, then set it to view again.

I think this would be a good feature to have in case some files are the result of something else being calculated when you read the file. I just needed this.

what

it's called stdout

>>3
Sure, you can always use a pipe and a process, but this only works if the program manually supports it; it's not file transparent.

>>4
any program that writes to stdout (meaning any program that outputs text) supports redirection, or "pipe and a process" as you put it.

you're talking about having separate data streams for a file for each process, which is asking too much of the filesystem.  is it really that much bother for a process to append something like it's pid, a guid, or a timestamp to a file name to insure unique files?

Actually, that shouldn't mess too much with the filesystem as all you'd need to add is a view flag, and a hook for open that will execute the contents of the file and make it available as a new, unique handle.

>>6
ok, but where do you store the data?  "making it available" means "making it available" *from somewhere* and unless you're talking about making it available from RAM (bad idea if output is going to be large), you are asking the filesystem to maintain multiple streams under one name. 

what advantage does setting an attribute have over making a second file containing the command's output.  explain how you have needed this.