Aros/Developer/Docs/Handlers/Pipe

The pipe handler is a named pipe handler, not an unnamed one like the original one. Could you create PIPE:mypipe in the original one? I don't remember so. Reading here it appears that indeed you could create named pipes:

Right now, for consistency reasons, opening PIPEFS: for reading or writing would result in an error, because PIPEFS: is a directory and treated as such. One could handle this as a special case and therefore we would just assign PIPE: to PIPEFS:. Alternatively, PIPEFS: could contain a special directory named __systempipe__ which would act like the original PIPE: did, also allowing to specify the other parameters bufsize and bufnum (ignoring them at the moment, maybe).

You can create files in our PIPEFS: and each file acts like a standard pipe. In fact it's the same as original PIPE: except one thing - you can't open file with empty name (just PIPE:). In original handler empty name is also name. To implement PIPE: we just assigned PIPE: to some named pipe created on startup, namely "systempipe". Yes, but this is redundant. In fact the above should be fixed and PIPEFS: can be renamed to just PIPE:. "You must provide a name after PIPE:, such as a filename". (DOS manual). Apparently using an empty name was an "unintended feature". OK, we'd probably want to mimic that as well, if we can, but we already seem to conform to specs. If we implemented this as a real file system, then we'll get into trouble with names like PIPE;//, but then, so does the original. OK, so if we assume the file name conventions hold, would the quick fix be to add a p in front of every file name? Does reduce the limit to the name, doesn't it? Well, the following mapping to a real file system might work, I guess:

pipedir
--unnamed
--nameddir
----<name1>
----<name2>

Of course, there's extra flexibility in having PIPE: being an assign, but probably also extra room to hang ourselves.

Actually, you had to create a file name in PIPE:, that's how the link was created, by having a process write into PIPE:samename and have another process read from PIPE:samename. I used to think that since the pipes were named anyway, why not allow multiple readers and/or writers, if the user so preferred. Never tried it out, though, I believe some alternatives did implement stuff like that. The unnamed one was the Pip command, I think, though I'd say that unnamed piping should really be a shell function.

In the current implementation we can't refer to something like PIPE:Some/Path/Name. We can use only PIPE:. In original pipe-handler pipes are auto-created when you open some new name for writing. Empty name is also valid there. BTW, note also custom FSA_PIPE and new Pipe() dos.library function. I would say they are bad solution. Why is some magic name (like $UNNAMED$) bad? DupLock() then could split two ends of a pipe. $UNMAMED$ is treated differently just for the purpose of the creation of pipes with popen() and similar functions: it gives you back a pipe handler but doesn't create file in the pipe fs, therefore any other opening of $UNNAMED$ opens a new pipe, just how popen() expects. popen() currently uses custom packet. Well, somebody changed it. ;-) Questionable choice, imho. I tend to shy away from magic names. You never know who'll have a reason to use them as ordinary ones. Maybe mapping it thus:

pipedir
--unnamed
--nameddir
----<name1>
----<name2>
--popendir
----<howeverthesework>
?

Or would we be unable to link the popen-ed pipes to the files, this way?

Just noticed that one whole new pipe handler was implemented for the occasion. I wonder: why?

In current implementation we can't refer to something like PIPE:Some/Path/Name. We can use only PIPE:. In original pipe-handler pipes are auto-created when you open some new name for writing. Empty name is also valid there.

BTW, note also custom FSA_PIPE and new Pipe() dos.library function. I would say they are bad solution. Why is some magic name (like $UNNAMED$) bad? DupLock() then could split two ends of a pipe.

Examples

Could you create PIPE:mypipe in the original one?

Yes you could. Even PIPE:Sub/mypipe.

References