如果您在搜尋中找到此頁面，您可能正在嘗試解決運行 bash 的某些問題。
也許您的 bash 環境沒有設定環境變量，而您不明白為什麼。 您可能在各種 bash 啟動檔案或設定檔或所有檔案中隨機插入了某些內容，直到它起作用為止。
無論如何，本文的重點是盡可能簡單地列出啟動 bash 的過程，以便您可以處理問題。
Диаграмма
此流程圖總結了運行 bash 時的所有流程。
現在讓我們仔細看看每個部分。
登入外殼？
首先您需要選擇是否處於登入 shell 中。
登入 shell 是您登入互動式會話時輸入的第一個 shell。 登入 shell 不需要使用者名稱和密碼。 您可以透過新增標誌來強制登入 shell 啟動 --login 當被調用時 bash例如：
bash--登入
當您首次啟動 bash shell 時，登入 shell 會設定基本環境。
互動的？
然後確定 shell 是否是互動的。
這可以透過變數的存在來檢查 PS1 （它安裝命令輸入功能）：
如果[“${PS1-}”]; then echo 互動式 else echo 非互動式 fi
或查看該選項是否設定 -i，使用特殊的連字符變數 - 在 bash 中，例如：
$迴聲$-
如果輸出中有一個符號 i，那麼 shell 是互動的。
在登入外殼中？
如果您在登入 shell 中，則 bash 會尋找該文件 /etc/profile 並運行（如果存在）。
然後按以下順序搜尋這三個文件中的任何一個：
〜/ .bash_profile 〜/ .bash_login 〜/ .profile
當它找到一個時，它會啟動它並跳過其他的。
在互動式 shell 中？
如果您處於非登入 shell 中，則假定您已經處於登入 shell 中，環境已設定並將被繼承。
在這種情況下，如果存在以下兩個文件，則按順序執行它們：
/etc/bash.bashrc ~/.bashrc
沒有選擇嗎？
如果您不在登入 shell 或互動式 shell 中，那麼您的環境確實是空的。 這會導致很多混亂（請參閱下面有關 cron 作業的內容）。
在這種情況下 bash 查看變數 BASH_ENV 您的環境並建立在那裡指定的相應文件。
常見困難和經驗法則
計劃任務
95% 的情況下，我調試 bash 啟動都是因為 cron 作業沒有如預期運作。
這該死的任務 當我在命令列上運行它時工作正常，但當我在 crontab 中運行它時失敗.
這裡 兩個原因:
- Cron 作業不是互動式的。
- 與命令列腳本不同，cron 作業不繼承 shell 環境。
通常，您不會注意到或關心 shell 腳本不是互動式的，因為環境繼承自互動式 shell。 這意味著一切 PATH и alias 按照您的預期配置。
這就是為什麼經常需要設定一個特定的 PATH 對於像這樣的 cron 任務：
* * * * * PATH=${PATH}:/path/to/my/program/資料夾 myprogram
腳本相互調用
另一個常見問題是腳本被錯誤地配置為相互呼叫。 例如， /etc/profile 是有吸引力對 ~/.bashrc.
當有人試圖修復某些錯誤並且一切似乎都正常時，通常會發生這種情況。 不幸的是，當您需要分離這些不同類型的會話時，就會出現新的問題。
沙盒 Docker 映像
為了試驗運行 shell，我建立了一個 Docker 映像，可用於在安全環境中偵錯執行 shell。
發射：
$ docker run -n bs -d imiell/bash_startup
$ docker exec -ti bs bashDockerfile 位於 .
強制登入並模擬登入 shell：
$ bash --login
測試一組變數 BASH_ENV:
$ env | grep BASH_ENV
用於調試 crontab 一個簡單的腳本將每分鐘執行一次（在 /root/ascript):
$ crontab -l
$ cat /var/log/script.log來源： www.habr.com