關于Shell腳本效率優(yōu)化的一些個人想法
更新時間：2012年09月02日 22:46:47 作者：
很想像之前的一片Mysql全面優(yōu)化詳解那樣子寫一篇全面的優(yōu)化文章，但是苦于沒有相關書籍參考，也沒有發(fā)現(xiàn)網(wǎng)絡牛人有總結帖或文章之類的，所以就根據(jù)個人理解和經(jīng)驗寫一些能優(yōu)化程序效率的東西吧。這篇是不敢稱全面的
一、先說一下Shell腳本語言自身的局限性
作為解釋型的腳本語言，天生就有效率上邊的缺陷。盡管它調(diào)用的其他命令可能效率上是不錯的。
Shell腳本程序的執(zhí)行是順序執(zhí)行，而非并行執(zhí)行的。這很大程度上浪費了可能能利用上的系統(tǒng)資源。
Shell每執(zhí)行一個命令就創(chuàng)建一個新的進程，如果腳本編寫者沒有這方面意識，編寫腳本不當?shù)脑挘欠浅＠速M系統(tǒng)資源的。
二、我們在Shell腳本語言的局限性上盡可能的通過我們有經(jīng)驗的編碼來提高腳本的效率。
1、比如我想做一個循環(huán)處理數(shù)據(jù)，可能是簡單的處理一下數(shù)據(jù)，這樣會讓人比較容易就想到Shell里的循環(huán)類似這樣：
sum=0
for((i=0;i<100000;i++))
do
sum=$(($sum+$i))
done
echo $sum
我們可以使用time這個腳本來測試一下十萬次循環(huán)的三次執(zhí)行耗時：
real 0m2.115s
user 0m1.975s
sys 0m0.138s
real 0m2.493s
user 0m2.173s
sys 0m0.254s
real 0m2.085s
user 0m1.886s
sys 0m0.195s
平均耗時2.2s，如果你知道awk命令里的循環(huán)的話，那更好了，我們來測試一下同數(shù)據(jù)規(guī)模的循環(huán)三次執(zhí)行耗時：
awk 'BEGIN{
sum=0;
for(i=0;i<100000;i++)
sum=sum+i;
print sum;
}'
real 0m0.023s
user 0m0.018s
sys 0m0.005s
real 0m0.020s
user 0m0.018s
sys 0m0.002s
real 0m0.021s
user 0m0.019s
sys 0m0.003s
你都不敢想象平均時間僅0.022s，基本上純循環(huán)的效率已經(jīng)比Shell高出兩位數(shù)量級了。事實上你再跑百萬次的循環(huán)你會發(fā)現(xiàn)Shell已經(jīng)比較吃力了，千萬級的更是艱難。所以你應該注意你的程序盡量使用awk來做循環(huán)操作。
2、關于正則，經(jīng)常寫Shell的同學都明白它的重要性，但是你真的能高效使用它嗎？
下邊舉個例子：現(xiàn)在我有一個1694617行的日志文件 action.log，它的內(nèi)容類似：
2012_02_07 00:00:04 1977575701 183.10.69.47 login 500004 1977575701 old /***/port/***.php?…
我現(xiàn)在想獲取//之間的port的字符串，我可以這樣：
awk -F'/' ‘{print $3}' < 7action.log > /dev/null
但是你不會想知道它的效率：
real 0m12.296s
user 0m12.033s
sys 0m0.262s
相信我，我不會再想看著光標閃12秒的。但是如果這樣執(zhí)行：
awk ‘{print $9}' < 7action.log | awk -F'/' '{print $3}' > /dev/null
這句的效率三次分別是：
real 0m3.691s
user 0m5.219s
sys 0m0.630s
real 0m3.660s
user 0m5.169s
sys 0m0.618s
real 0m3.660s
user 0m5.150s
sys 0m0.612s
平均時間大概3.6秒，這前后效率大概有4倍的差距，雖然不像上一個有百倍的差距，但是也足夠讓4小時變成1小時了。我想你懂這個差距的。
其實這個正則實例你可以嘗試推測其他的情況，因為正則每次運行都是需要啟動字符串匹配的，而且默認的分隔符會較快的按字段區(qū)分出。所以我們在知道一些數(shù)據(jù)規(guī)律之后可以嘗試大幅度的縮短我們將要進行復雜正則匹配的字符串，這樣會根據(jù)你縮減數(shù)據(jù)規(guī)模有一個非常明顯的效率提升，上邊還是驗證的比較簡單的正則匹配情況，只有一個單字符“\”,你可以試想如果正則表達式是這樣：
$7!~/\.jpg$/&&$7~/\.[s]?html|\.php|\.xml|\/$/&&($9==200||$9==304)&&$1!~/^103\.108|^224\.215|^127\.0|^122\.110\.5/
我想你可以想象的出一個目標匹配字符串從500個字符縮減到50個字符的時候的巨大意義！
ps：另外詳細的正則優(yōu)化請看這個日期之后發(fā)的一篇博文。
3、再說一下shell的重定向和管道。這個條目我不會再舉例子，只是說一下我個人的理解。
周所周知，很多程序或者語言都有一個比較突出的效率瓶頸就是IO，Shell也不例外（個人這么考慮）。所以建議盡可能的少用重定向來進行輸入輸出這樣的操作或者創(chuàng)建臨時文件來供后續(xù)使用，當然，如果必須這么干的時候那就這么干吧，我只是講一個盡量的過程。
我們可以用Shell提供的管道來實現(xiàn)命令間數(shù)據(jù)的傳遞。如果進行連續(xù)的對數(shù)據(jù)進行過濾性命令的時候，盡量把一次性過濾較多的命令放在前邊，這個原因都懂吧？減少數(shù)據(jù)傳遞規(guī)模。
最后我想說的連管道也盡量的少用的，雖然管道比正常的同定向IO快幾個數(shù)量級的樣子，但是那也是需要消耗額外的資源的，好好設計你的代碼來減少這個開銷吧。比如sort | uniq 命令，完全可以使用 sort -u 來實現(xiàn)。
4、再說一下Shell腳本程序的順序執(zhí)行。這塊的優(yōu)化取決于你的系統(tǒng)負載是否達到了極限，如果你的系統(tǒng)連命令的順序執(zhí)行負載都到了一個較高的線的話，你就沒有必要進行Shell腳本程序的并行改造了。下邊給出一個例子，如果你要模仿這個優(yōu)化，請保證你的系統(tǒng)還能有負載空間。比如現(xiàn)在有這樣一個程序：
supportdatacommand1
supportdatacommand2
supportdatacommand3
supportdatacommand4
supportdatacommand5
supportdatacommand6
need13datacommand
need24datacommand
need56datacommand
大意就是有6個提供數(shù)據(jù)的命令在前邊，后面有3個需要數(shù)據(jù)的命令，第一個需要數(shù)據(jù)的命令需要數(shù)據(jù)13，第二個需要24，第三個需要56。但是正常情況下Shell會順序的執(zhí)行這些命令，從supportdatacommand1,一條一條執(zhí)行到need56datacommand。這樣的過程你看著是不是也很蛋疼？明明可以更好的做這一塊的，蛋疼的程序可以這樣改造：
supportdatacommand1 &
supportdatacommand2 &
supportdatacommand3 &
supportdatacommand4 &
supportdatacommand5 &
supportdatacommand6 &
#2012-02-22 ps：這里的循環(huán)判斷后臺命令是否執(zhí)行完畢是有問題的，pidnum循#環(huán)減到最后也還是1不會得到0值，具體解決辦法看附錄，因為還有解釋，就不在這#里添加和修改了。
while true
do
sleep 10s
pidnum=`jobs -p | wc -l`
if [ $pidnum -le 0 ]
then
echo "run over"
break
fi
done
need13datacommand &
need24datacommand &
need56datacommand &
wait
...
可以類似上邊的改造。這樣改造之后蛋疼之感就紓解的多了。但還是感覺不是很暢快，那好吧，我們可以再暢快一點（我是指程序。。。），可以類似這樣：
for((i=0;i<1;i++));do
{
command1
command2
}&
done
for((i=0;i<1;i++));do
{
command3&
command4&
}&
done
for((i=0;i<1;i++));do
{
command5 &
command6 &
if 5 6執(zhí)行完畢...
command7
}&
done
這樣類似這樣的改造，讓有前后關系的命令放在一個for循環(huán)里讓他們一起執(zhí)行去，這樣三個for循環(huán)其實是并行執(zhí)行了。然后for循環(huán)內(nèi)部的命令你還可以類似改造1的那種方式改造或者內(nèi)嵌改造2這個的并行for循環(huán)，都是可以的，關鍵看你想象力了。恩？哦，不對，關鍵是看這些個命令之間是一種什么樣的基友關系了。有關聯(lián)的放一個屋里就行了，剩下的你就不用操心了。嘿嘿~~
其實這個優(yōu)化真的需要看系統(tǒng)負載。
5、關于對shell命令的理解。這個條目就靠經(jīng)驗了，因為貌似沒有相關的書籍可看，如果誰知道有，請推薦給我，我會灰常感謝的啊。
比如：sed -n '45,50p' 和 sed -n '51q;45,50p' ，前者也是讀取45到50行，后者也是，但是后者到51行就執(zhí)行了退出sed命令，避免了后續(xù)的操作讀取。如果這個目標文件的規(guī)模巨大的話，剩下的你懂的。
還有類似sed ‘s/foo/bar/g' 和sed ‘/foo/ s/foo/bar/g'
sed支持采用正則進行匹配和替換，考慮字符串替換的需求中，不防加上地址以提高速度。實例中通過增加一個判斷邏輯，采用“事先匹配”代替“直接替換”，由于sed會保留前一次的正則匹配環(huán)境，不會產(chǎn)生冗余的正則匹配，因此后者具有更高的效率。關于sed命令的這兩點優(yōu)化，我也在sed命令詳解里有提到。
還有類似sort 如果數(shù)字盡量用 -n選項；還有統(tǒng)計文件行數(shù)，如果每行的數(shù)據(jù)在占用字節(jié)數(shù)一樣的情況時就可以ls查文件大小然后除以每行的數(shù)據(jù)大小的出行數(shù)，而避免直接使用wc -l這樣的命令；還有find出來的數(shù)據(jù)，別直接就-exec選項了，如果數(shù)據(jù)規(guī)模小很好，但是如果你find出來上千條數(shù)據(jù)或更多，你會瘋掉的，不，系統(tǒng)會瘋掉的，因為每行數(shù)據(jù)都會產(chǎn)生新的進程，你可以這樣find …. | xargs ….；還有…(如果你也知道類似的提效率情況請你告訴我共同進步！)
三、關于優(yōu)化更好的一些選擇
一個比較好的提升Shell腳本的效率方法就是…… 就是…… 就是…… 好吧，就是盡量少用Shell（別打我?。。。。┫逻吔o出一些debian官方統(tǒng)計的一些在linux系統(tǒng)上邊的各個語言的效率圖，咱都以C++為比較基準（系統(tǒng)規(guī)格：x64 Ubuntu™ Intel® Q6600® quad-core）：
這些圖的查看方法，比如第一個圖java和c++的程序效率比較圖，總共分三個部分，分別是time、memory、code的比較，如果是c++/java ，就是說 c++做比較的分子，java做比較的分母，如果圖上的長條在哪邊，說明所在的那邊的程序使用的時間或者內(nèi)存或者代碼較多，具體多多少就看長條長了多少。每一部分有多個長條圖形，每個長條圖案表示針對程序處理不同方面的任務時進行的測試。比如第一幅，c++和java在該環(huán)境下大部分情況下time上是差不多的，甚至java-server還有稍微的優(yōu)勢，內(nèi)存方面c++就有很大優(yōu)勢，能夠使用比java少的多的內(nèi)容做相同的事情，但是編碼量c++就稍微多一點點。以下的圖類似。
解決方法暫時有兩個（具體沒有解釋，不太清楚原因）：
1、
sleep 8 &
sleep 16 &
while true
do
echo `jobs -p | wc -l`
jobs -l >> res
sleep 4
done
2、 檢查剩余個數(shù)的語句改成 jobs -l |grep -v “Done”|wc -l
第一個方案的解決是多執(zhí)行一次jobs，可以解釋成為了消除最后的Done結果，但是這種解釋也是行不通的，因為循環(huán)是一直執(zhí)行的，在echo里已經(jīng)執(zhí)行很多次jobs了，何止一次。
第二個方案是過濾掉jobs最后的輸出結果Done這條語句。算是繞過問題得到了期待的結果。
個人感覺bash解釋器優(yōu)化掉了沒有后臺命令執(zhí)行的jobs查詢命令，如果是優(yōu)化掉了那也應該有個空的返回，wc依然可以得到0的結果啊。所以這個問題找不到具體原因，如果你知道請告訴我，非常感謝。。。 這里先感謝just do shell群里的Eric 沉默的土匪 GS 三人，非常感謝你們的幫助。
這里兩個方法不算好方法，只是奇怪這樣為什么不行，行的又該如何解釋。后來知道用wait命令就全解決了，耽誤那么多時間還是用的不明智的方法。
轉載請注明：三江小渡厚道喔！
作為解釋型的腳本語言，天生就有效率上邊的缺陷。盡管它調(diào)用的其他命令可能效率上是不錯的。
Shell腳本程序的執(zhí)行是順序執(zhí)行，而非并行執(zhí)行的。這很大程度上浪費了可能能利用上的系統(tǒng)資源。
Shell每執(zhí)行一個命令就創(chuàng)建一個新的進程，如果腳本編寫者沒有這方面意識，編寫腳本不當?shù)脑挘欠浅＠速M系統(tǒng)資源的。
二、我們在Shell腳本語言的局限性上盡可能的通過我們有經(jīng)驗的編碼來提高腳本的效率。
1、比如我想做一個循環(huán)處理數(shù)據(jù)，可能是簡單的處理一下數(shù)據(jù)，這樣會讓人比較容易就想到Shell里的循環(huán)類似這樣：
復制代碼 代碼如下:
sum=0
for((i=0;i<100000;i++))
do
sum=$(($sum+$i))
done
echo $sum
我們可以使用time這個腳本來測試一下十萬次循環(huán)的三次執(zhí)行耗時：
real 0m2.115s
user 0m1.975s
sys 0m0.138s
real 0m2.493s
user 0m2.173s
sys 0m0.254s
real 0m2.085s
user 0m1.886s
sys 0m0.195s
平均耗時2.2s，如果你知道awk命令里的循環(huán)的話，那更好了，我們來測試一下同數(shù)據(jù)規(guī)模的循環(huán)三次執(zhí)行耗時：
復制代碼 代碼如下:
awk 'BEGIN{
sum=0;
for(i=0;i<100000;i++)
sum=sum+i;
print sum;
}'
real 0m0.023s
user 0m0.018s
sys 0m0.005s
real 0m0.020s
user 0m0.018s
sys 0m0.002s
real 0m0.021s
user 0m0.019s
sys 0m0.003s
你都不敢想象平均時間僅0.022s，基本上純循環(huán)的效率已經(jīng)比Shell高出兩位數(shù)量級了。事實上你再跑百萬次的循環(huán)你會發(fā)現(xiàn)Shell已經(jīng)比較吃力了，千萬級的更是艱難。所以你應該注意你的程序盡量使用awk來做循環(huán)操作。
2、關于正則，經(jīng)常寫Shell的同學都明白它的重要性，但是你真的能高效使用它嗎？
下邊舉個例子：現(xiàn)在我有一個1694617行的日志文件 action.log，它的內(nèi)容類似：
2012_02_07 00:00:04 1977575701 183.10.69.47 login 500004 1977575701 old /***/port/***.php?…
我現(xiàn)在想獲取//之間的port的字符串，我可以這樣：
awk -F'/' ‘{print $3}' < 7action.log > /dev/null
但是你不會想知道它的效率：
real 0m12.296s
user 0m12.033s
sys 0m0.262s
相信我，我不會再想看著光標閃12秒的。但是如果這樣執(zhí)行：
awk ‘{print $9}' < 7action.log | awk -F'/' '{print $3}' > /dev/null
這句的效率三次分別是：
real 0m3.691s
user 0m5.219s
sys 0m0.630s
real 0m3.660s
user 0m5.169s
sys 0m0.618s
real 0m3.660s
user 0m5.150s
sys 0m0.612s
平均時間大概3.6秒，這前后效率大概有4倍的差距，雖然不像上一個有百倍的差距，但是也足夠讓4小時變成1小時了。我想你懂這個差距的。
其實這個正則實例你可以嘗試推測其他的情況，因為正則每次運行都是需要啟動字符串匹配的，而且默認的分隔符會較快的按字段區(qū)分出。所以我們在知道一些數(shù)據(jù)規(guī)律之后可以嘗試大幅度的縮短我們將要進行復雜正則匹配的字符串，這樣會根據(jù)你縮減數(shù)據(jù)規(guī)模有一個非常明顯的效率提升，上邊還是驗證的比較簡單的正則匹配情況，只有一個單字符“\”,你可以試想如果正則表達式是這樣：
$7!~/\.jpg$/&&$7~/\.[s]?html|\.php|\.xml|\/$/&&($9==200||$9==304)&&$1!~/^103\.108|^224\.215|^127\.0|^122\.110\.5/
我想你可以想象的出一個目標匹配字符串從500個字符縮減到50個字符的時候的巨大意義！
ps：另外詳細的正則優(yōu)化請看這個日期之后發(fā)的一篇博文。
3、再說一下shell的重定向和管道。這個條目我不會再舉例子，只是說一下我個人的理解。
周所周知，很多程序或者語言都有一個比較突出的效率瓶頸就是IO，Shell也不例外（個人這么考慮）。所以建議盡可能的少用重定向來進行輸入輸出這樣的操作或者創(chuàng)建臨時文件來供后續(xù)使用，當然，如果必須這么干的時候那就這么干吧，我只是講一個盡量的過程。
我們可以用Shell提供的管道來實現(xiàn)命令間數(shù)據(jù)的傳遞。如果進行連續(xù)的對數(shù)據(jù)進行過濾性命令的時候，盡量把一次性過濾較多的命令放在前邊，這個原因都懂吧？減少數(shù)據(jù)傳遞規(guī)模。
最后我想說的連管道也盡量的少用的，雖然管道比正常的同定向IO快幾個數(shù)量級的樣子，但是那也是需要消耗額外的資源的，好好設計你的代碼來減少這個開銷吧。比如sort | uniq 命令，完全可以使用 sort -u 來實現(xiàn)。
4、再說一下Shell腳本程序的順序執(zhí)行。這塊的優(yōu)化取決于你的系統(tǒng)負載是否達到了極限，如果你的系統(tǒng)連命令的順序執(zhí)行負載都到了一個較高的線的話，你就沒有必要進行Shell腳本程序的并行改造了。下邊給出一個例子，如果你要模仿這個優(yōu)化，請保證你的系統(tǒng)還能有負載空間。比如現(xiàn)在有這樣一個程序：
supportdatacommand1
supportdatacommand2
supportdatacommand3
supportdatacommand4
supportdatacommand5
supportdatacommand6
need13datacommand
need24datacommand
need56datacommand
大意就是有6個提供數(shù)據(jù)的命令在前邊，后面有3個需要數(shù)據(jù)的命令，第一個需要數(shù)據(jù)的命令需要數(shù)據(jù)13，第二個需要24，第三個需要56。但是正常情況下Shell會順序的執(zhí)行這些命令，從supportdatacommand1,一條一條執(zhí)行到need56datacommand。這樣的過程你看著是不是也很蛋疼？明明可以更好的做這一塊的，蛋疼的程序可以這樣改造：
復制代碼 代碼如下:
supportdatacommand1 &
supportdatacommand2 &
supportdatacommand3 &
supportdatacommand4 &
supportdatacommand5 &
supportdatacommand6 &
#2012-02-22 ps：這里的循環(huán)判斷后臺命令是否執(zhí)行完畢是有問題的，pidnum循#環(huán)減到最后也還是1不會得到0值，具體解決辦法看附錄，因為還有解釋，就不在這#里添加和修改了。
while true
do
sleep 10s
pidnum=`jobs -p | wc -l`
if [ $pidnum -le 0 ]
then
echo "run over"
break
fi
done
need13datacommand &
need24datacommand &
need56datacommand &
wait
...
可以類似上邊的改造。這樣改造之后蛋疼之感就紓解的多了。但還是感覺不是很暢快，那好吧，我們可以再暢快一點（我是指程序。。。），可以類似這樣：
復制代碼 代碼如下:
for((i=0;i<1;i++));do
{
command1
command2
}&
done
for((i=0;i<1;i++));do
{
command3&
command4&
}&
done
for((i=0;i<1;i++));do
{
command5 &
command6 &
if 5 6執(zhí)行完畢...
command7
}&
done
這樣類似這樣的改造，讓有前后關系的命令放在一個for循環(huán)里讓他們一起執(zhí)行去，這樣三個for循環(huán)其實是并行執(zhí)行了。然后for循環(huán)內(nèi)部的命令你還可以類似改造1的那種方式改造或者內(nèi)嵌改造2這個的并行for循環(huán)，都是可以的，關鍵看你想象力了。恩？哦，不對，關鍵是看這些個命令之間是一種什么樣的基友關系了。有關聯(lián)的放一個屋里就行了，剩下的你就不用操心了。嘿嘿~~
其實這個優(yōu)化真的需要看系統(tǒng)負載。
5、關于對shell命令的理解。這個條目就靠經(jīng)驗了，因為貌似沒有相關的書籍可看，如果誰知道有，請推薦給我，我會灰常感謝的啊。
比如：sed -n '45,50p' 和 sed -n '51q;45,50p' ，前者也是讀取45到50行，后者也是，但是后者到51行就執(zhí)行了退出sed命令，避免了后續(xù)的操作讀取。如果這個目標文件的規(guī)模巨大的話，剩下的你懂的。
還有類似sed ‘s/foo/bar/g' 和sed ‘/foo/ s/foo/bar/g'
sed支持采用正則進行匹配和替換，考慮字符串替換的需求中，不防加上地址以提高速度。實例中通過增加一個判斷邏輯，采用“事先匹配”代替“直接替換”，由于sed會保留前一次的正則匹配環(huán)境，不會產(chǎn)生冗余的正則匹配，因此后者具有更高的效率。關于sed命令的這兩點優(yōu)化，我也在sed命令詳解里有提到。
還有類似sort 如果數(shù)字盡量用 -n選項；還有統(tǒng)計文件行數(shù)，如果每行的數(shù)據(jù)在占用字節(jié)數(shù)一樣的情況時就可以ls查文件大小然后除以每行的數(shù)據(jù)大小的出行數(shù)，而避免直接使用wc -l這樣的命令；還有find出來的數(shù)據(jù)，別直接就-exec選項了，如果數(shù)據(jù)規(guī)模小很好，但是如果你find出來上千條數(shù)據(jù)或更多，你會瘋掉的，不，系統(tǒng)會瘋掉的，因為每行數(shù)據(jù)都會產(chǎn)生新的進程，你可以這樣find …. | xargs ….；還有…(如果你也知道類似的提效率情況請你告訴我共同進步！)
三、關于優(yōu)化更好的一些選擇
一個比較好的提升Shell腳本的效率方法就是…… 就是…… 就是…… 好吧，就是盡量少用Shell（別打我?。。。。┫逻吔o出一些debian官方統(tǒng)計的一些在linux系統(tǒng)上邊的各個語言的效率圖，咱都以C++為比較基準（系統(tǒng)規(guī)格：x64 Ubuntu™ Intel® Q6600® quad-core）：
這些圖的查看方法，比如第一個圖java和c++的程序效率比較圖，總共分三個部分，分別是time、memory、code的比較，如果是c++/java ，就是說 c++做比較的分子，java做比較的分母，如果圖上的長條在哪邊，說明所在的那邊的程序使用的時間或者內(nèi)存或者代碼較多，具體多多少就看長條長了多少。每一部分有多個長條圖形，每個長條圖案表示針對程序處理不同方面的任務時進行的測試。比如第一幅，c++和java在該環(huán)境下大部分情況下time上是差不多的，甚至java-server還有稍微的優(yōu)勢，內(nèi)存方面c++就有很大優(yōu)勢，能夠使用比java少的多的內(nèi)容做相同的事情，但是編碼量c++就稍微多一點點。以下的圖類似。
通過上邊的圖我看可以知道C++在時間和空間上對Python、Perl、PHP有著絕對壓倒性的優(yōu)勢，但是相對的編碼量較高。同java比只有內(nèi)存使用上的優(yōu)勢。但是我們這篇主要是針對Shell的，但是，又是但是，debian官網(wǎng)沒有把shell腳本納入效率比較的統(tǒng)計范圍?。。。∵€是但是，我們知道Python、Perl、PHP都是號稱對Shell在效率方面有著明顯的優(yōu)勢，所以你如果不滿意你通過以上提供的種種優(yōu)化途徑后的Shell腳本程序的話，那你就可以嘗試換一種語言了。
但是我們往往不那么容易舍棄這么好用方便而且簡單的處理數(shù)據(jù)方式，也可以有個折中的方法，你先用time測試各個Shell腳本命令的耗時，針對特別耗時，特別讓人不能忍受的命令的效率使用C++程序處理，讓你的Shell腳本來調(diào)用這個針對局部數(shù)據(jù)處理的C++程序，這樣折中貌似還是能讓人接受吧？
四、最后說一下這篇是不敢稱為全面或者詳解的文章，是我對這一段Shell學習和實踐的一些心得，希望能有高手指點。也希望能幫到新踏入這一領域的新同學。以后有新的心得再添加吧。
感謝這篇文章的作者的博文指點。
2012-02-22 ps：循環(huán)檢測后臺命令是否結束的判斷修改：解決方法暫時有兩個（具體沒有解釋，不太清楚原因）：
1、
復制代碼 代碼如下:
sleep 8 &
sleep 16 &
while true
do
echo `jobs -p | wc -l`
jobs -l >> res
sleep 4
done
2、 檢查剩余個數(shù)的語句改成 jobs -l |grep -v “Done”|wc -l
第一個方案的解決是多執(zhí)行一次jobs，可以解釋成為了消除最后的Done結果，但是這種解釋也是行不通的，因為循環(huán)是一直執(zhí)行的，在echo里已經(jīng)執(zhí)行很多次jobs了，何止一次。
第二個方案是過濾掉jobs最后的輸出結果Done這條語句。算是繞過問題得到了期待的結果。
個人感覺bash解釋器優(yōu)化掉了沒有后臺命令執(zhí)行的jobs查詢命令，如果是優(yōu)化掉了那也應該有個空的返回，wc依然可以得到0的結果啊。所以這個問題找不到具體原因，如果你知道請告訴我，非常感謝。。。 這里先感謝just do shell群里的Eric 沉默的土匪 GS 三人，非常感謝你們的幫助。
這里兩個方法不算好方法，只是奇怪這樣為什么不行，行的又該如何解釋。后來知道用wait命令就全解決了，耽誤那么多時間還是用的不明智的方法。
轉載請注明：三江小渡厚道喔！
相關文章
這篇文章主要介紹了 Linux 中（加、減、乘、除）實例詳解的相關資料,需要的朋友可以參考下2017-05-05
這篇文章主要介紹了SHELL腳本read命令的具體用法，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2020-05-05
type命令用來顯示指定命令的類型，它是Linux系統(tǒng)的一種自省機制，知道了是那種類型，我們就可以針對性的獲取幫助，這篇文章主要介紹了linux?type命令用法實戰(zhàn)教程,需要的朋友可以參考下2023-05-05
這篇文章主要介紹了sed?-i?命令入門教程,sed?本身是一個非常復雜的工具，有專門的書籍講解?sed?的具體用法，網(wǎng)上也有很多關于?sed?的教程，我也是抱著學習的心態(tài)來學習?sed?的常見的用法，并進行系統(tǒng)的總結，內(nèi)容基本覆蓋了?sed?的大部分的知識點2022-06-06
由于機器數(shù)量眾多,因此采用批量修改密碼的方式來進行處理,本文主要介紹了shell批量修改主機密碼的實現(xiàn)示例,具有一定的參考價值,感興趣的可以了解一下2023-12-12
這篇文章主要介紹了useradd命令使用方法,還包括用戶賬號的添加、刪除與修改、用戶口令的管理、用戶組的管理方法，大家參考使用吧2014-01-01
本文主要介紹了Shell腳本自動部署項目的方法步驟，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2023-03-03
本文主要介紹了結合示例說明shell是如何被解析的，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2021-12-12
這篇文章主要為大家詳細介紹了Shell實現(xiàn)猜數(shù)字游戲，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2020-04-04
這篇文章主要介紹了Shell腳本獲取進程的運行時間,需要的朋友可以參考下2014-06-06