除了 PATH 變數之外，找不到命令錯誤的可能原因是什麼？
在 Linux 中找不到命令的可能原因有哪些？除了它不在
PATH？一些背景資料：
在嘗試從 vscode 執行 pdflatex 時，我遇到了一些麻煩，即 vscode 無法找到 pdflatex。可能是因為
PATH設置不正確。由於我無法立即解決這個問題，我嘗試通過執行一個 shell 腳本來解決這個問題，然後呼叫 pdflatex：#!/bin/bash export PATH=/usr/bin pdflatex $@或者
#!/bin/bash /usr/bin/pdflatex $@在這兩種情況下，腳本在普通終端上執行時都按預期工作。但是當在 vscode 實習生終端中執行時，它會說
pdflatex: command not found據我所知，找不到命令的唯一方法是，如果它不在
PATH. 或者當絕對路徑錯誤時。但這似乎不是這裡的情況。那麼還有哪些其他因素用於確定，如何搜尋命令？附加資訊（作為請求）
- 作業系統：POP OS 21.04
- 從 vscode 終端：
$ echo $PATH /app/bin:/usr/bin:/home/flo/.var/app/com.visualstudio.code
- 從本機終端：
$ echo $PATH /opt/anaconda3/bin:/opt/anaconda3/condabin:/home/flo/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
- 目錄中的其他命令 as
ls也/usr/bin可以從 vscode 內部終端（ls以及/usr/bin/ls）工作。- pdflatex的屬性：
$ ls -l /usr/bin/pdflatex lrwxrwxrwx 1 root root 6 Feb 17 2021 /usr/bin/pdflatex -> pdftex
- 或者
$file /usr/bin/pdflatex /usr/bin/pdflatex: symbolic link to pdftex
- 和 pdftex（與 pdflatex 的行為相同）：
$ ls -l /usr/bin/pdftex -rwxr-xr-x 1 root root 2115048 Mar 13 2021 /usr/bin/pdftex
- 或者
$ file /usr/bin/pdftex /usr/bin/pdftex: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=88c89d7d883163b4544f9461668b73383e1ca04e, for GNU/Linux 3.2.0, stripped
- 以下腳本也提供相同的輸出：
#!/bin/bash pdflatex $@
- 原始（複製，沒有任何編輯）腳本如下：
#!/bin/bash #export PATH=/usr/bin #printenv PATH pdflatex $@ #/usr/bin/pdflatex $@為了測試其他腳本，我更改了評論並刪除了文章中不相關的行。
/app/bin不存在。（/app不存在）- 我試圖更改
PATHin vscode （在 LaTeX Workshop 擴展中），因為這很可能是我的問題的首要原因。但是，我既無法解決問題，也無法以任何方式確認我的配置（用於 LaTeX Workshop 擴展）根本沒有任何效果。- 將以下行添加到腳本時（
makeTex.sh是我的包裝腳本）：declare -p LD_LIBRARY_PATH declare -p LD_PRELOAD輸出如下： 本機終端：
./makeTex.sh: line 4: declare: LD_LIBRARY_PATH: not found ./makeTex.sh: line 5: declare: LD_PRELOAD: not foundvscode終端：
declare -x LD_LIBRARY_PATH="/app/lib" ./makeTex.sh: line 5: declare: LD_PRELOAD: not found
- 使用 vscode 1.57.1（通過 flatpak 安裝）出現問題。其他版本的 vscode（至少 vscodium 1.60.1）不顯示相同的行為。
有趣的是，在一個過度配置的 zsh 環境（使用 oh-my-zsh）中安裝新軟體包後，我遇到了一個新命令找不到。我可以確認這不是 zsh 中的預設行為。顯然，zsh 中有一個可用命令的“記憶體”，可以將其配置為不自動刷新。
一些愚蠢的稻草人認為，在一般基礎上防範路徑上的 nfs 條件或 ram-starved-system 條件是明智的。我不喜歡 oh-my-zsh 以及人們安裝和讚譽的所有這些花哨的樣式/配置。他媽的炒作軟體。
我想你的問題在這裡得到了回答：
確保您沒有取消設置 hash_list_all (…)
zstyle “:completion:*:commands” rehash 1
就我而言，我可以按照此答案中的說明檢查上述選項：
$ unsetopt | grep hash; echo ---; setopt | grep hash nohashcmds nohashdirs hashexecutablesonly nohashlistall ---另一種可能性是環境被清除/初始化，而不是您對 IDE 的期望。但是，/usr/bin 不在 PATH 中似乎很奇怪。創建一個新腳本，從 IDE 執行它並列印環境以確認您的假設：
env > /tmp/env-in-script-from-ide
你的環境很亂。
從內部終端執行以下命令並驗證輸出（您不必使用 head 截斷路徑輸出）。使用 pdflatex 而不是 gzip，或者兩者都嘗試。如果你的普通終端和可視程式碼終端的輸出不同，那是因為環境不同。
我猜你是通過 Snap 安裝了視覺化程式碼，並且它有一個有限或孤立的環境。
$ env | grep ^PATH= | tr : \\n | head -n 3; echo; which gzip; gzip --version | head -n1 ; echo $SHELL PATH=vendor/bin node_modules/.bin /home/jaroslav/bin /bin/gzip gzip 1.10 /bin/bash在我的環境中，這完美無缺。可視程式碼終端和 urxvt 中的輸出相同。
$ env | grep ^PATH= | tr : \\n | head -n 3; echo; which pdflatex; pdflatex --version | head -n1 ; echo $SHELL PATH=vendor/bin node_modules/.bin /home/jaroslav/bin /usr/bin/pdflatex pdfTeX 3.141592653-2.6-1.40.22 (TeX Live 2021 Gentoo Linux) /bin/bash膠乳
壓縮包
urxvt
