ogrep rs
0.6.0
用於搜尋縮排結構文字檔案的功能工具。
靈感來自 Matt Brubeck 的 ogrep。那個 ogrep 緊湊而美觀，但功能不豐富。
另請參閱 ogrep — 這個用 Python 編寫的工具的連接埠（說實話，它是第一個）。
ogrep很像grep ，兩者都可以搜尋匹配項並顯示其上下文。但是grep中的上下文是“匹配之前/之後的 N 行”，而在ogrep中它是“匹配的行上方具有較低的縮進”。
讓我解釋一下。我主要在處理 GN 建置檔案時使用此工具，因此我將使用一些大型 BUILD.gn 檔案作為範例。通常的任務是搜尋原始檔案名稱並了解哪個目標包含該檔案以及在什麼條件下包含該檔案。
讓我們找到「arena.cc」文件的提及：
# grep arena.cc BUILD.gn
"base/arena.cc",
好的，現在我們的文件在這裡，但不知道目標。讓我們詢問一些背景：
# grep -C2 arena.cc BUILD.gn
"base/address_tracker_linux.cc",
"base/address_tracker_linux.h",
"base/arena.cc",
"base/arena.h",
"base/backoff_entry.cc",
不，沒那麼有用。讓我們嘗試一下ogrep ：
ogrep arena.cc BUILD.gn
102: component("net") {
385: if (!is_nacl) {
386: sources += [
409: "base/arena.cc",
現在這很有用！我們立即知道該檔案在“!is_nacl”條件下包含到“net”目標中。
那就更好了，因為ogrep可以使用顏色，這是一張圖片：
安裝 Rust 和 Cargo，如果還沒有，那麼
cargo install ogrep安裝 Homebrew，然後
brew install kriomant/ogrep-rs/ogrep-rs抱歉，還沒有，但我正在努力。現在使用 Cargo。
有很多可用的選項，使用--help運行來列出它們。
該工具不僅對於嚴格基於縮排的檔案（如Python 原始碼）或GN 建置檔案有用，而且對於廣泛的文字檔案也很有用，因為即使是不基於縮排的檔案通常也會為了方便而進行格式化。
甚至還內建了一些與 C 相關的 hack。
這是簡要的功能清單：
預設情況下，模式是固定文本，但您可以透過-e使用任意正則表達式。
可以使用常用的-w （匹配整個單字）和-i （不區分大小寫的搜尋）。
工具在匹配之間保留一些空白行，因為它有助於在視覺上分隔相關匹配組，您可以使用--no-breaks將其關閉。
有時，查看匹配的行之間是否還有其他行很有用。使用--ellipsis來實現這一點。
如果將otool與外部工具集成， --print-filename選項可能很有用，它告訴列印檔案名稱（如果找到任何符合項目）。
預設情況下，「if-else」分支會被特殊處理：if-分支會被保留，因此即使在「else」分支中找到匹配項，您也知道條件：
--context/-C 、 --before-context/-B和--after-context/-A選項也支援傳統上下文（在匹配的一行周圍顯示 N 個前導行和/或尾隨行）。
# ./ogrep filename_util_icu BUILD.gn
102: component("net") {
2106: if (!is_nacl) {
2210: if (use_platform_icu_alternatives) {
2222: } else {
2228: sources += [
2229: "base/filename_util_icu.cc",
可使用--no-smart-branches關閉此功能。
--no-ignore-preprocessor為止。計劃對預處理器指令（並行上下文）進行更聰明的處理。
otool旨在僅在單一文件中搜尋。而且它對於搜尋許多文件來說並不是那麼快。但您可以將其與其他搜尋工具集成，如下所示：
grep -l cache_used -r . --include='*.cc' | xargs -n1 ogrep --print-filename cache_used
git grep支援ogrep與git grep具有內建整合：當給出-g選項時，第二個參數將作為路徑規範傳遞給git grep 。所有相關選項（ -w 、 -i等）也會自動傳遞給git grep ， --print-filename是強制的。
ogrep -g cache_used '*.cc'
