在更高的層面上…

在更高的層面上…

這幾天我一直在努力尋找資訊。需要明確的是,我的目標是建立一個ncurses類似 C 的函式庫。我完全清楚ANSI 轉義序列以及如何使用它們。然而我想要可移植性,因此我對terminfo資料庫感興趣。我已經閱讀了部分文檔,例如:

它讓我了解理論和原理,但在實踐中我找不到任何關於如何使用 C 等程式語言存取/連接資料庫的範例。

目前我想到的唯一方法是將terminfo資料庫二進位檔案加載到記憶體中並手動執行對其的訪問,但我應該構建自己的方案並且沒有更簡單/實用/官方的方法似乎很奇怪訪問這些該死的資料庫。

答案1

要存取 FreeBSD 上的 termcap 資料庫,有作業系統中的一種方式。 FreeBSD C 函式庫有一個用於存取的 API能力資料庫。所以getcap()等人。是呼叫以存取較低層級的 termcap 資料庫的函數。 (實際上存在較低層級的 API,但它們並沒有像 API 那樣抽像出getcap()功能資料庫可以是使用程式建構的可變長度記錄平面檔案或適當索引的二進位資料庫檔案這一事實cap_mkdb。)

更高層次的是tgetent()tputs()、 等。並且您正在嘗試建立自己的“類似 ncurses”的庫。 (在基於 Linux 的作業系統上,它們是 terminfo ncurses 庫的一部分。)

無需透過 ncurses 自己的 terminfo API 即可存取 terminfo 資料庫記錄的範例是 unibilium 庫。 NeoVIM 使用這個。

在更高的層面上…

terminfo/termcap 的想法是更便攜到了21世紀的第二個十年,它確實已經達到了臨界點甚至更遠。您幾乎肯定不會遇到不符合 ECMA-48:1976 標準的真正視訊終端,更不用說紙質終端了。 terminfo 抽象通常與真實視訊終端的功能不符,在某些方面是一種障礙可移植性,因為它們強制採用一種有些扭曲的工作方式。

這尤其適用於終端機輸入,實際上自 20 世紀 80 年代初以來一直是 ECMA-48(帶有一些用於 RXVT、Interix、Linux KVT 和 SCO Console 的狀態機 bodges),並且匹配固定字符串的 termcap/terminfo 模型非常差合身。但「本地」/「xmit」計算器鍵盤、「遊標尋址模式」以及只有三種形式的遊標表現等理念也與終端的實際工作方式不符。

如果你如果要重新發明 ncurses,那麼請至少不要複製它的顏色對模型。這幾乎不符合 ECMA-48 和 AIXterm 顏色系統,更不用說終端機已經使用了四分之一個多世紀的 ITU T.416 索引和直接顏色機制。

進一步閱讀

相關內容