我寫完指令碼興奮的準備去執行這個指令碼，殊不知，指令碼執行的方式也是很有講究的。目前掌握的執行指令碼的方式有如下幾種：
1. 直譯器 + script_name
2. ./ + script_name
(.+指令碼路徑+scrpit_name)
3. source + script_name
4. . + script_name
這麼多種執行方式，到底要選哪一種呢，確實很矇圈，別急，先了解一下各個執行方式的區別，再做選擇。
直譯器 + script_name :
先寫好乙個bash指令碼，賦予可執行許可權，指令碼第一行加上「#!」(還記得沒)
然後，我們使用「直譯器 + script_name」的方式執行這個指令碼，可以看到我的/home/目錄下有兩個資料夾，其中ls是我們指令碼中建立的。此時的shell還是在「liushuo」這個路徑下。
看起來第二種執行方式和第一種沒有什麼區別
可以發現執行結果是與1和2一樣的，但是可以發現，我們執行指令碼時候的路徑是在/liushuo/這個路徑，而執行結束之後工作的路徑跳轉到/home/了，也就是我指令碼中「cd /home/」在當前的shell發生了作用。
可以發現這種執行方式與第三種效果是一樣的。
總結一下，前兩種執行指令碼的方式，不會對當前的shell發生影響,指令碼執行其實是在乙個sub shell中執行的；而後兩種執行方式，指令碼在當前shell中執行，會對當前shell發生影響。了解了區別之後，就要分具體情況選擇不同的執行指令碼的方式了。
比如我們修改個人的.cshrc檔案，這個檔案是在每次新起terminal才會發生作用，如果想在當前shell下起作用，就可以用source 或者 . 的方式執行，立竿見影；如果想執行乙個編寫好的指令碼，不改變當前shell，比如我們提job的時候，那就可以選擇前兩種方式了。
one more thing : 有小夥伴說分享一下shell正規表示式,em...好飯不怕晚，再看了，再看了！
crontab執行指令碼出錯
最近經常碰到關於crontab不能執行的，初步總結了有以下幾個原因 第一，指令碼的原因 大多數情況下，是我們的指令碼的問題，這種問題導致crontab不能執行的概率佔到70 以上。因為程式執行到某一步導致crontab終止執行，如，資料庫訪問出錯等。第二，執行環境問題，當我們碰到第一情況下，一般都可...
crontab 中指令碼不執行
在集群上，crontab e新增了乙個指令碼run.sh每天自動執行，但到其中的qsub run.job，不能自動提交pbs。手動執行run.sh,可以提交指令碼並成功執行。在指令碼中新增所有要用到的環境變數路徑等，source ww3.env 環境變數檔案 參考 crontab有乙個壞毛病，就是它...
crontab計畫執行指令碼詳解
crontab是linux系統中在固定時間執行某乙個程式的工具，類似於windows系統中的任務計畫程式。一 安裝crontab yum install vixie cron 安裝 chkconfig crond on 設為開機啟動，安裝chkconfig yum installchkconfig ...