Aros/開發人員/文件/處理程式/管道

現在，出於一致性原因，開啟 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。

參考文獻