Aros/开发人员/文档/处理程序/管道
管道处理程序是一个命名管道处理程序，而不是像原始管道处理程序那样是匿名管道。您可以在原始管道处理程序中创建 PIPE:mypipe 吗？我不记得了。阅读 这里，似乎您确实可以创建命名管道。
现在，出于一致性原因，打开 PIPEFS: 用于读写会导致错误，因为 PIPEFS: 是一个目录并被视为目录。可以将此作为特殊情况处理，因此我们将 PIPE: 赋给 PIPEFS:。或者，PIPEFS: 可以包含一个名为 __systempipe__ 的特殊目录，该目录的作用类似于原始 PIPE:，还可以指定其他参数 bufsize 和 bufnum（目前忽略它们，也许可以）。
您可以在我们的 PIPEFS: 中创建文件，每个文件都像一个标准管道。事实上，它与原始 PIPE: 相同，只有一点不同 - 您不能打开没有名称的文件（仅仅是 PIPE:）。在原始处理程序中，空名称也是名称。为了实现 PIPE:，我们只是将 PIPE: 赋给启动时创建的某个命名管道，即“systempipe”。是的，但这很冗余。事实上，上面应该修正，PIPEFS: 可以改名为 PIPE:。“您必须在 PIPE: 之后提供一个名称，例如文件名”。（DOS 手册）。显然，使用空名称是一个“意外功能”。好的，我们可能也想模仿它，如果可以的话，但我们似乎已经符合规范。如果我们将其实现为一个真正的文件系统，那么我们会遇到 PIPE:// 这样的名称问题，但原始文件系统也是如此。好的，因此如果我们假设文件名约定成立，那么快速修复方法是在每个文件名之前添加一个 p 吗？这是否会减少名称的限制？好吧，以下映射到真实文件系统可能有效，我认为
pipedir --unnamed --nameddir ----<name1> ----<name2>
当然，将 PIPE: 作为赋值会带来额外的灵活性，但也可能带来额外的错误风险。
实际上，您必须在 PIPE: 中创建一个文件名，这就是链接的创建方式，通过让一个进程写入 PIPE:samename 并让另一个进程从 PIPE:samename 读取。我曾经认为，由于管道本身就是命名的，为什么不允许用户在需要的情况下允许多个读取器和/或写入器呢？但我从未尝试过，我相信一些替代方案确实实现了类似的东西。匿名管道是 Pip 命令，我认为，不过我认为匿名管道应该是一个 Shell 函数。
在当前实现中，我们不能引用像 PIPE:Some/Path/Name 这样的东西。我们只能使用 PIPE:。在原始管道处理程序中，当您打开某个新名称以进行写入时，管道会自动创建。空名称在那里也是有效的。另外，还要注意自定义 FSA_PIPE 和新的 Pipe() dos.library 函数。我认为它们是一个糟糕的解决方案。为什么某个神奇名称（比如 $UNNAMED$）不好？DupLock() 然后可以拆分管道的两个端点。$UNMAMED$ 在创建使用 popen() 和类似函数的管道的目的方面被不同地对待：它为您返回一个管道处理程序，但不创建管道 fs 中的文件，因此任何其他打开 $UNNAMED$ 的操作都会打开一个新的管道，就像 popen() 所期望的那样。popen() 当前使用自定义数据包。好吧，有人改变了它。 ;-) 我认为这是一个可疑的选择。我倾向于避免使用神奇名称。您永远不知道谁会出于某种原因将它们用作普通名称。也许将其映射为
pipedir --unnamed --nameddir ----<name1> ----<name2> --popendir ----<howeverthesework> ?
或者我们无法以这种方式将 popen-ed 管道链接到文件吗？
刚注意到为这个场合实现了一个全新的管道处理程序。我想知道：为什么呢？
在当前实现中，我们不能引用像 PIPE:Some/Path/Name 这样的东西。我们只能使用 PIPE:。在原始管道处理程序中，当您打开某个新名称以进行写入时，管道会自动创建。空名称在那里也是有效的。
另外，还要注意自定义 FSA_PIPE 和新的 Pipe() dos.library 函数。我认为它们是一个糟糕的解决方案。为什么某个神奇名称（比如 $UNNAMED$）不好？DupLock() 然后可以拆分管道的两个端点。
您可以在原始管道处理程序中创建 PIPE:mypipe 吗？
是的，您可以在。甚至 PIPE:Sub/mypipe。