ref: https://wiki.bash-hackers.org/howto/redirection_tutorial
本篇是個 Linux 相關的教學文，專注於透過視覺化的方式來教學到底 shell 上常常使用的 >, 2>&1 等差異是什麼。
舉例來說，你能不能清楚的說出下列兩種用法的差異，實際上 fd 到底會怎麼運作?
1. > file 2>&1
2. 2>&1 > file

亦或是某些 shell script 常看到 exec 2>log 到底是什麼意思?

本篇文章解釋得非常清除，透過 /dev/pts 這種 pseudo terminal 為起點，將 0(stdin), 1(stdout), 2(stderr) 三個 fd 給視覺化呈現。
基於這個概念開始探討下列不同指令實際上 fd 會有什麼變化

# Simple Redirections
">" 應該是最為簡單也最廣為人知的用法，command > file 的方式將輸入(stdout)給導入檔案(file)。
那加上數字後會有什麼變化呢? 譬如 command 1>file, command 3>file ？

下一個不能不知的就是 pipe 的概念，透過 pipe 能夠組合出各種指令來解決問題，到底 pipe(|) 的過程中這些 fd 是什麼變化?

# More On File Descriptors
另外一個很常被問到的用法就是，有沒有辦法將 stderr 跟 stdout 一起輸出?
這時候可能就會看到 1>&2 2>&1 等各種答案，那到底這些語法的背後是什麼意思?

非常推薦所有人都仔細閱讀這篇文章重新複習/學習這類型操作的底層變化。

ref: https://cmdchallenge.com/#/hello_world

今天分享的是一個有趣的 Command Line Interface(CLI) 挑戰，該挑戰主要是基於 Linux bash 的環境有一系列的指令挑戰

挑戰內容基本上都不會太困難，一開始都是非常基礎的 Linux 指令操作，後面會需要使用 grep, sed, awk, find 等不同指令的組合來完成任務。
大部分的題目都會基於一些情境，譬如想要針對 httpd server 底下的 log 進行過濾，計算符合某些內容的行數等等

每道題目除了自行挑戰外也可以看一下別人的解決方案，不過解決方案中有一些是作弊的內容，譬如直接針對題目用 echo 輸出之類的，就滿搞笑的。

我認為這類型的挑戰有兩個值得去玩看看的理由
1. 測試自已是否能夠解決每一個問題，順便看一下自己的解決方式跟別人的比起來如何，有時候會有一些意想不到的指令與用法可以讓整個寫法更為簡潔
2. 如果有面試需求的時候，可以考慮從這邊找一些相關題目，看看面試者對於 shell script 的熟悉度，同時互相討論每個解法的好壞處。

歡迎愛寫 shell script 的人都寫一遍看看

剛剛在整理筆記的時候，發現兩年半前還在前公司就應該要發的文章一直躺在筆記裡面，快點整理一下 po 出來。

---

這是第三篇關於 log 的文章，應該也是最後一篇了，這次來聊聊如何讓開發者用 log 了解自己發出的 API 流程是否正確及如何提升效率。

強者小編同事用 python 寫的 log 整理工具，其實就是把 AP 吐出來的一堆多行 debug log，轉成只有 header、url、執行時間的單行 log。所以其實可以把產生出的 API log 再用其他 Linux 指令，即時顯示給開發者看。

---

這麼做的好處不少，對 frontend 來說，可以避免下列問題發生：

1. API 誤用：A 畫面應該是要串 a API，可是卻串到了 b API，又或是串成了 a' API。串成 b 是有點誇張啦，但最近 review 後發現 a' API 倒是比較常出現，像是參數帶錯之類的。
2. 誤解 API 流程：流程應該是串 abc，可是卻串成了 acb。有時候這不是什麼大問題，但在注重流程的 App 上這就很嚴重了。
3. API 狂發：流程應該是串 abc，但卻變成了 abbbcc。這個問題在使用上比較難發現，因為會有這類問題的大都是 GET API，依 RESTful GET API 的 idempotent 特性，無論執行多少次 GET，結果都會是一樣，所以也就更難發現問題了。

---

對 backend 來說的好處也不少：

1. 了解 cache 設計方向：像是剛剛的第 3 點問題，在 frontend 還沒更版前，backend 可以先加上 Cache-Control 機制，把大量的無效 request 從資料庫轉移到 Cache 裡面，當然 frontend 本來就要有這機制才行。
2. 了解每支 API 的效率：開發 API 沒幾個重點，就是流程正確、執行速度快，其中執行速度也是最難處理的一塊。所以了解 API 的處理速度，才有辦法做最佳化。

用這套工具就可以把上面提到的幾個重點一一檢視，也發了十幾個 issue 給 frontend 及 backend，算是 CP 值很高的一個開發。

---

至於技術細節，其實也就下面兩個重點而已：

1. 用 SocketIO 建置一套 WebSocket Server，然後放兩個輸入框，表示要訂閱 (subscribe) 的 log 來源及要監視的 user id
2. 用 tail -f 將 log 即時 pipe 到強者同事寫的 log 整理工具，再用 awk 把需要的欄位輸出，最後將輸出的欄位發送到 WebSocket Server

這個即時顯示 log 的網頁從發想到完成，工時應該只有兩三個小時吧，但發揮的效用可說是非常的大，今天就靠這個網頁開了十幾張單，算是最近小編蠻能說嘴的一項工作了吧 XDDD

* https://www.facebook.com/kewang.information/posts/2058766574399706
* https://www.facebook.com/kewang.information/posts/2085843121692051

#socketio #websocket #log