Aros/Developer/Docs/Handlers/Pipe

Introduction
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

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 --popendir ?

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.