一、標準輸入和參數的區別
這個問題一定是最容易讓人迷惑的，具體來說，就是搞不清什麼時候用管道符|和文件重定向>，
比如說，我現在有個自動連接寬帶的 shell 腳本connect.sh，存在我的家目錄：
<code>$ where connect.sh
/home/fdl/bin/connect.sh
/<code>
如果我想刪除這個腳本，而且想少敲幾次鍵盤，應該怎麼操作呢？我曾經這樣嘗試過：
<code>$ where connect.sh | rm
/<code>
實際上，這樣操作是錯誤的，正確的做法應該是這樣的：
<code>$ rm $(where connect.sh)
/<code>
前者試圖將where的結果連接到rm的標準輸入，後者試圖將結果作為命令行參數傳入。
標準輸入就是編程語言中諸如scanf或者readline這種命令；而參數是指程序的main函數傳入的args字符數組。
管道符和重定向符是將數據作為程序的標準輸入，而$(cmd)是讀取cmd命令輸出的數據作為參數，前文畫圖解釋過：
輸入重定向就是說，程序想讀取數據的時候就會去 files[0] 讀取，所以我們只要把 files[0] 指向一個文件，那麼程序就會從這個文件中讀取數據，而不是從鍵盤。
同理，輸出重定向就是把files[1]指向一個文件，那麼程序的輸出就不會寫入到顯示器，而是寫入到這個文件中。
管道符其實也是異曲同工，把一個進程的輸出流和另一個進程的輸入流接起一條「管道」，數據就在其中傳遞：
Linux 進程、線程、文件描述符的底層原理
用剛才的例子說，rm命令源代碼中肯定不接受標準輸入，而是接收命令行參數，刪除相應的文件。作為對比，cat命令是既接受標準輸入，又接受命令行參數：
<code>$ cat filename
...file text...
$ cat < filename
...file text...
$ echo 'hello world' | cat
hello world
/<code>
如果命令能夠讓終端阻塞，說明該命令接收標準輸入，反之就是不接受，比如你只運行cat命令不加任何參數，終端就會阻塞，等待你輸入字符串並回顯相同的字符串。
二、後臺運行程序
比如說你遠程登錄到服務器上，運行一個 Django web 程序：
<code>$ python manager.py runserver 0.0.0.0
Listening on 0.0.0.0:8080...
/<code>
現在你可以通過服務器的 IP 地址測試 Django 服務，但是終端此時就阻塞了，你輸入什麼都不響應，除非輸入 Ctrl-C 或者 Ctrl-/ 終止 python 進程。
可以在命令之後加一個&符號，這樣命令行不會阻塞，可以響應你後續輸入的命令，但是如果你退出服務器的登錄，就不能訪問該網頁了。
如果你想在退出服務器之後仍然能夠訪問 web 服務，應該這樣把命令包裹成這樣(cmd &)：
<code>$ (python manager.py runserver 0.0.0.0 &)
Listening on 0.0.0.0:8080...
$ logout
/<code>
底層原理是這樣的：
每一個命令行終端都是一個 shell 進程，你在這個終端裡執行的程序實際上都是這個 shell 進程分出來的子進程。正常情況下，shell 進程會阻塞，等待子進程退出才重新接收你輸入的新的命令。加上&號，只是讓 shell 進程不再阻塞，可以繼續響應你的新命令。但是無論如何，你如果關掉了這個 shell 命令行端口，依附於它的所有子進程都會退出。
而(cmd &)這樣運行命令，則是將cmd命令掛到一個systemd系統守護進程名下，認systemd做爸爸，這樣當你退出當前終端時，對於剛才的cmd命令就完全沒有影響了。
類似的，還有一種後臺運行常用的做法是這樣：
<code>$ nohup some_cmd &
/<code>
nohup命令也是類似的原理，不過通過我的測試，還是(cmd &)這種形式更加穩定。
三、單引號和雙引號的區別
不同的 shell 行為會有細微區別，但有一點是確定的，對於$，(，)這幾個符號，單引號包圍的字符串不會做任何轉義，雙引號包圍的字符串會轉義。
shell 的行為可以測試，使用set -x命令，會開啟 shell 的命令回顯，你可以通過回顯觀察 shell 到底在執行什麼命令：
可見 echo $(cmd) 和 echo "$(cmd)"，結果差不多，但是仍然有區別。注意觀察，雙引號轉義完成的結果會自動增加單引號，而前者不會。
也就是說，如果 $ 讀取出的參數字符串包含空格，應該用雙引號括起來，否則就會出錯。
四、sudo 找不到命令
有時候我們普通用戶可以用的命令，用sudo加權限之後卻報錯 command not found：
<code>$ connect.sh
network-manager: Permission denied
$ sudo connect.sh
sudo: command not found
/<code>
原因在於，connect.sh這個腳本僅存在於該用戶的環境變量中：
<code>$ where connect.sh
/home/fdl/bin/connect.sh
/<code>
當使用sudo時，系統認為是 root 用戶在執行命令，所以會去搜索 root 用戶的環境變量，而這個腳本在 root 的環境變量目錄中當然是找不到的。
解決方法是使用腳本文件的路徑，而不是僅僅通過腳本名稱：
<code>$ sudo /home/fdl/bin/connect.sh
/<code>
以上就是全部內容，對於出現的一些難以理解的現象，要多思考和嘗試，熟練之後，shell 命令行真的可以帶來很大的便利。
閱讀更多 IT小白進階之路 的文章
