最近在TL的討論中忽然有人挑起了perl和python（一場關(guān)于c++的討論扯到腳步上還有不少的碰撞，倒是挺有意思），我則有感而發(fā)的想起了前幾天面試的時候問別人的一個基本的shell問題：
cat xxx.txt | grep "yyy" | wc –l
問題是這個常見的pipeline操作一般最少會起多少個進程？結(jié)果那位老兄倒是愣了半天然后目無表情。
我只好繼續(xù)嘮叨的解釋了一下一般pipe的操作需要讀取一個進程的輸入，然后將輸出送給下一個進程；其實我希望對方干脆利落的回答是有3個，這個問題就算是可以了；我們主要不是用腳本開發(fā)，但是如果有這個技能是能得到額外的認可的。
TL上的大蝦們果然是想法眾多，立馬有人站出來問：我想知道答案是幾個？直接讓我懷疑是不是我的腦袋有問題。后來有人給出了可能是2個的情形：
某個變態(tài)的shell可能內(nèi)置了cat,使其成為一個builtin，然后自己越俎代庖的讀取標準輸入，并且將內(nèi)容文本輸出，那么進程就少一個。
起初我覺得這個解釋并不能成立，但是經(jīng)過幾個老大的解釋還是明白了他所說的情況是shell的builtin。
中間又討論起那些可能是builtin的command，舉出的例子是cd/kill/time，但是我查了一下Solaris上的，后兩個都是executable，cd找到一個/usr/bin/cd 的ksh，內(nèi)容如下：
#!/bin/ksh
command = `basename $0`
$command $@
這個結(jié)果本來還是挺出乎我的意料的，于是我也想當然的認為，shell里邊不能直接調(diào)用syscall；
很快就得證這個揣測純粹是錯誤的；以前還真沒想過這個問題，查了下wikipedia、google之后得到很多意料之外的收獲。
最后居然有人搬出了busybox這個大旗（做過嵌入式的大多都知道些），并聲稱它把vi也builtin了。
這下也很出乎我的意料，不顧我沒有仔細研究過，沒有什么發(fā)言權(quán)。
不過最后有人站出來說，busybox并沒有內(nèi)置這些想當然的vi，而是大部分也單獨起進程了；在Unix的哲學(xué)里邊，做這些大而全的東西其實是不被鼓勵的，因為它違反unix的哲學(xué)。
話說回來，面試的時候，我之所以會問到這樣的問題，也是有很真實的background的。曾經(jīng)我們查過的一個很詭異的performance bottleneck就是由于shell腳步的問題引起的。
====================================================================================================
問題本身也是比較直觀的（當然是“事后諸葛”了）：
某段程序的啟動腳本使用如下的東東來檢測環(huán)境：
exists=`netstat -rn | grep "xx.xx.xx.xx" | wc -l`
if [ $exists -eq 0 ];then
idx=`ifconfig -an | grep bge0 | awk -F":" '{print $2}' | uniq | sort | tail`"
ifconfig bge0:`echo $idx + 1 | bc` plumb up
ifconfig bge0:`echo $idx + 1 | bc` xx.xx.xx.xx netmask 255.255.255.0
fi
當有很多個同樣的進程（>500)恰好于同一時刻跑到這個初始化點的時候，如果系統(tǒng)上已經(jīng)存在的IP地址很多（當時的場景大概有2000+），那么netstat、ifconfig本身都變得非常耗時，加上多個進程的原因，系統(tǒng)中會有N多個進程在消耗著資源；
后果的嚴重程度是任何shell都停止響應(yīng)，數(shù)十分鐘都陷入假死，不得不重啟電源了事。
當然的分析結(jié)果發(fā)現(xiàn)，真正占用的CPU都是處于kernel狀態(tài)的，并且使用率超過99%，長長的pipeline帶來的開銷，相當一部分可能來源于互相等待CPU的進程的互相搶占。
解決的方法自然也很簡單，這里不贅述了。
=========================================================================
當時以為對這個問題搞得算是比較明白了，結(jié)果拿出來一討論，發(fā)現(xiàn)自己不了解的還真不少。