Linux 上應用程式利用使用者資料夾的標準

整個 Linux 作業系統怎麼安排檔案系統，有 Filesystem Hierarchy Standard (FHS) 作為參考標準，在使用者資料夾 (Home directory; ~/) 的部分，目前主要應該都是參考 XDG Base Directory 來放。

使用者設定: $XDG_CONFIG_HOME (~/.config/)

使用者為應用程式做的偏好設定。

使用者資料: $XDG_DATA_HOME (~/.local/share/)

存放類似書籤、憑證、郵件、金鑰等使用者操作應用程式所得到或產生的資料，期待資料格式應具備一定程度的可攜性，使用者可能會想要備份這些資料。

應用程式狀態: $XDG_STATE_HOME (~/.local/state/)

存放像是執行紀錄 (log) 檔、最近存取資料的紀錄、視窗最後位置等，可以用在應用程式啟動時初始狀態的資料，使用者備份這些資料可能沒有太多意義。

使用者自行安裝的程式: ~/.local/bin/

各 distribution 應該自動的在這個資料夾存在時，把他加到使用者的 $PATH 環境變數中。

雖然沒有那麼常見，但最好可以考慮使用者資料夾可能會在不同處理器架構的主機間共用的情形。

規格中另外有定義一些環境變數，用來指定搜尋資料的順序。

在 WSL 2 上掛載 USB disk

如果要在 WSL 2 (Windows Subsystem for Linux) 掛載在 Linux 格式 (EXT4, XFS ... etc.) 的 USB 外接磁碟，可以先試試看這篇 Mount a Linux disk in WSL 2 說的方法，萬一不行再去試 Connect USB devices 的方式。

雖然第一篇說該方法針對的是內部儲存裝置，外接式裝置無法支援，但我自己在 Windows 11 (23H2; build 22631) 試是可以的。反而透過 USBIPD 的方式，因為 WSL 提供的 kernel 沒有包含 USB mass storage 的驅動程式，雖然 lsusb 看得到裝置，但是沒辦法掛載起來使用。

Markdown

目前都是基於 CommonMark 上面再去增加語法或限制，疊在 CommonMark 上面新增的規格稱為 extension。

Extension 在函式庫看起來作法大概是這樣:

1. 解析部份目前都是產生 AST 再去生成輸出，大概有兩種讓 extension 介入解析的方式:
   1. 讓 extension 實作註冊關注的字元，再去觸發解析與 AST 加工。
   2. 掃出來的 AST 整個讓 extension 實作再去解析與加工。
2. 完成 AST 之後再進行 render 來產生輸出，看起來多半是讓 extension 註冊處理所屬 token 型別的輸出函式，在 render 時呼叫來處理生成輸出的作業。

直接從 Markdown 產生 HTML 的方式因為比較難擴充的關係，即使有機會比較快，但現在看起來比較不流行了。

Ref:

• GitHub (GFM) 的規格: https://github.github.com/gfm/
• Visual Studio Code 用的引擎: https://github.com/markdown-it/markdown-it
• CommonMark: https://spec.commonmark.org/
• Go: https://github.com/gomarkdown/markdown
• Go: https://gitlab.com/golang-commonmark/markdown
• 規格的範例本身可以當成 test suite: https://github.com/commonmark/commonmark-spec
• 在 CommonMark.org 首頁提到的 test suite: https://github.com/michelf/mdtest
• Markdown Guide 有一些最佳建議實踐與常見的 extension 使用說明: https://www.markdownguide.org/
• GFM 規格發表公告，有說明所謂「移轉到 CommonMark 上」的背景: https://github.blog/2017-03-14-a-formal-spec-for-github-markdown/