歡迎光臨
每天分享高質量文章

面向系統管理員的 Bash 指南 | Linux 中國

使 Bash 工作的更好的技巧。
— Maxim Burgerhout


致謝
編譯自 | 
https://opensource.com/article/18/7/admin-guide-bash
 
 作者 | Maxim Burgerhout
 譯者 | Liang Chen (Flowsnow) 共計翻譯:20 篇 貢獻時間:989 天

使 Bash 工作的更好的技巧。

每個行業都有一個該行業的大師們最常使用的工具。 對於許多系統管理員來說,這個工具就是他們的 shell[1]。 在大多數 Linux 和其他類 Unix 系統上,預設的 shell 是 Bash。

Bash 是一個相當古老的程式——它起源於 20 世紀 80 年代後期——但它建立在更多更老的 shell 上,比如 C shell(csh),csh 至少是它 10 年前的前輩了。 因為 shell 的概念是那麼古老,所以有大量的神秘知識等待著系統管理員去吸收領悟,使其生活更輕鬆。

我們來看看一些基礎知識。

在某些時候,誰曾經無意中以 root 身份運行命令並導致某種問題? 舉手

我很確定我們很多人一度都是那個人。 這很痛苦。 這裡有一些非常簡單的技巧可以防止你再次碰上這類問題。

使用別名

首先,為 mv 和 rm 等命令設置別名,指向 mv -i 和 rm -i。 這將確保在運行 rm -f /boot 時至少需要你確認。 在 Red Hat 企業版 Linux 中,如果你使用 root 帳戶,則預設設置這些別名。

如果你還要為普通用戶帳戶設置這些別名,只需將這兩行放入家目錄下名為 .bashrc 的檔案中(這些也適用於 sudo ):

  1. alias mv='mv -i'

  2. alias rm='rm -i'

讓你的 root 提示符脫穎而出

你可以採取的防止意外發生的另一項措施是確保你很清楚在使用 root 帳戶。 在日常工作中,我通常會讓 root 提示符從日常使用的提示符中脫穎而出。

如果將以下內容放入 root 的家目錄中的 .bashrc 檔案中,你將看到一個黑色背景上的紅色的 root 提示符,清楚地表明你(或其他任何人)應該謹慎行事。

  1. export PS1="\[$(tput bold)$(tput setab 0)$(tput setaf 1)\]\u@\h:\w # \[$(tput sgr0)\]"

實際上,你應該盡可能避免以 root 用戶身份登錄,而是通過 sudo 運行大多數系統管理命令,但這是另一回事。

使用了一些小技巧用於防止使用 root 帳戶時的“不小心的副作用”之後,讓我們看看 Bash 可以幫助你在日常工作中做的一些好事。

控制你的歷史

你可能知道在 Bash 中你按向上的箭頭時能看見和重新使用你之前所有(好吧,大多數)的命令。這是因為這些命令已經儲存到了你家目錄下的名為 .bash_history 的檔案中。這個歷史檔案附帶了一組有用的設置和命令。

首先,你可以通過鍵入 history 來查看整個最近的命令歷史記錄,或者你可以通過鍵入 history 30 將其限製為最近 30 個命令。不過這技巧太平淡無奇了(LCTT 譯註: vanilla 原為香草,後引申沒拓展的、標準、普通的,比如 vanilla C++ compiler 意為標準 C++ 編譯器)。 你可以更好地控制 Bash 儲存的內容以及儲存方式。

例如,如果將以下內容添加到 .bashrc,那麼任何以空格開頭的命令都不會儲存到歷史記錄串列中:

  1. HISTCONTROL=ignorespace

如果你需要以明文形式將密碼傳遞給一個命令,這就非常有用。 (是的,這太可怕了,但它仍然會發生。)

如果你不希望經常執行的命令充斥在歷史記錄中,請使用:

  1. HISTCONTROL=ignorespace:erasedups

這樣,每次使用一個命令時,都會從歷史記錄檔案中刪除之前出現的所有相同命令,並且只將最後一次呼叫儲存到歷史記錄串列中。

我特別喜歡的歷史記錄設置是 HISTTIMEFORMAT 設置。 這將在歷史記錄檔案中在所有的條目前面添加上時間戳。 例如,我使用:

  1. HISTTIMEFORMAT="%F %T  "

當我輸入 history 5 時,我得到了很好的完整信息,如下所示:

  1. 1009  2018-06-11 22:34:38  cat /etc/hosts

  2. 1010  2018-06-11 22:34:40  echo $foo

  3. 1011  2018-06-11 22:34:42  echo $bar

  4. 1012  2018-06-11 22:34:44  ssh myhost

  5. 1013  2018-06-11 22:34:55  vim .bashrc

這使我更容易瀏覽我的命令歷史記錄並找到我兩天前用來建立到我家實驗室的 SSH 連接(我一次又一次地忘記……)。

Bash 最佳實踐

我將在編寫 Bash 腳本時最好的(或者至少是好的,我不要求無所不知)11 項實踐列出來。

11、 Bash 腳本可能變得複雜,不過註釋也很方便。 如果你在考慮是否要添加註釋,那就添加一個註釋。 如果你在周末之後回來並且不得不花時間搞清楚你上周五想要做什麼,那你是忘了添加註釋。

10、 用花括號括起所有變數名,比如 ${myvariable}。 養成這個習慣可以使用 ${variable}_suffix 這種用法了,還能提高整個腳本的一致性。

9、 計算運算式時不要使用反引號;請改用 $() 語法。 所以使用:

  1. for  file in $(ls); do

而不使用:

  1. for  file in `ls`; do

前一個方式是可嵌套的,更易於閱讀的,還能讓一般的系統管理員群體感到滿意。 不要使用反引號。

8、 一致性是好的。 選擇一種風格併在整個腳本中堅持下去。 顯然,我喜歡人們選擇 $() 語法而不是反引號,並將其變數包在花括號中。 我更喜歡人們使用兩個或四個空格而不是製表符來縮進,但即使你選擇了錯誤的方式,也要一貫地錯下去。

7、 為 Bash 腳本使用適當的釋伴shebang[2](LCTT 譯註:Shebang,也稱為 Hashbang ,是一個由井號和嘆號構成的字符序列 #! ,其出現在文本檔案的第一行的前兩個字符。 在檔案中存在釋伴的情況下,類 Unix 操作系統的程式載入器會分析釋伴後的內容,將這些內容作為解釋器指令,並呼叫該指令,並將載有釋伴的檔案路徑作為該解釋器的引數)。 因為我正在編寫Bash腳本,只打算用 Bash 執行它們,所以我經常使用 #!/usr/bin/bash 作為我的釋伴。 不要使用 #!/bin/sh 或 #!/usr/bin/sh。 你的腳本會被執行,但它會以兼容樣式運行——可能會產生許多意外的副作用。 (當然,除非你想要兼容樣式。)

6、 比較字串時,在 if 陳述句中給變數加上引號是個好主意,因為如果你的變數是空的,Bash 會為這樣的行丟擲一個錯誤:

  1. if [ ${myvar} == "foo" ]; then

  2.  echo "bar"

  3. fi

對於這樣的行,將判定為 false

  1. if [ "${myvar}" == "foo" ]; then

  2.  echo "bar"

  3. fi

此外,如果你不確定變數的內容(例如,在解析用戶輸入時),請給變數加引號以防止解釋某些特殊字符,並確保該變數被視為單個單詞,即使它包含空格。

5、 我想這是一個品味問題,但我更喜歡使用雙等號( == ),即使是比較 Bash 中的字串。 這是一致性的問題,儘管對於字串比較,只有一個等號會起作用,我的思維立即變為“單個 =是一個賦值運算子!”

4、 使用適當的退出代碼。 確保如果你的腳本無法執行某些操作,則會向用戶顯示已寫好的失敗訊息(最好提供解決問題的方法)併發送非零退出代碼:

  1. # we have failed

  2. echo "Process has failed to complete, you need to manually restart the whatchamacallit"

  3. exit 1

這樣可以更容易地以編程方式從另一個腳本呼叫你的腳本並驗證其成功完成。

3、 使用 Bash 的內置機製為變數提供合理的預設值,或者如果未定義你希望定義的變數,則丟擲錯誤:

  1. # this sets the value of $myvar to redhat, and prints 'redhat'

  2. echo ${myvar:=redhat}

  1. # this throws an error reading 'The variable myvar is undefined, dear reader' if $myvar is undefined

  2. ${myvar😕The variable myvar is undefined, dear reader}

2、 特別是如果你正在編寫大型腳本,或者是如果你與其他人一起開發該大型腳本,請考慮在函式內部定義變數時使用 local 關鍵字。 local 關鍵字將創建一個區域性變數,該變數只在該函式中可見。 這限制了變數衝突的可能性。

1、 每個系統管理員有時必須這樣做:在控制臺上除錯一些東西,可能是資料中心的真實服務器,也可能是虛擬化平臺的虛擬服務器。 如果你必須以這種方式除錯腳本,你會感謝你自己記住了這個:不要讓你的腳本中的行太長!

在許多系統上,控制台的預設寬度仍為 80 個字符。 如果你需要在控制臺上除錯腳本並且該腳本有很長的行,那麼你將成為一個悲傷的熊貓。 此外,具有較短行的腳本—— 預設值仍為 80 個字符——在普通編輯器中也更容易閱讀和理解!

我真的很喜歡 Bash。 我可以花幾個小時寫這篇文章或與其他愛好者交流優秀的技巧。 就希望你們能在評論中留下贊美。


via: https://opensource.com/article/18/7/admin-guide-bash

作者:Maxim Burgerhout[4] 選題:lujun9972 譯者:Flowsnow 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出

赞(0)

分享創造快樂