What are possible causes to the command not found error, other than the PATH variable?

Question

What are some possible causes, that a command could not be found in Linux? Other than it is not in the PATH?

Some background info:

When trying to execute pdflatex from vscode, I got some troubles, that vscode was not able to find pdflatex. Probably because the PATH is not set correctly. Since I was not able to fix the problem right away, I tried to work around this problem by executing a shell script, which then calls pdflatex:

#!/bin/bash 
export PATH=/usr/bin 
pdflatex $@ 

or

#!/bin/bash 
/usr/bin/pdflatex $@ 

In both cases, the script works as expected when executed over the normal terminal. But when executed in the vscode intern terminal it says

pdflatex: command not found

As far as I know, the only way that a command can not be found, is if it is not in a directory included by the PATH. Or when the absolute path is wrong. But this seems not to be the case here. So what other factors are used to determine, how a command is searched for?

Additional Infos (as requestet)

• OS: POP OS 21.04

• from vscode terminal:

  $ echo $PATH
  /app/bin:/usr/bin:/home/flo/.var/app/com.visualstudio.code
  

• from a native terminal:

  $ 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
  

• Other Commands as ls, which are also in /usr/bin directory do work from the vscode internal terminal (as ls aswell /usr/bin/ls).

• properties of pdflatex:

  $ ls -l /usr/bin/pdflatex
  lrwxrwxrwx 1 root root 6 Feb 17  2021 /usr/bin/pdflatex -> pdftex
  

• or

  $file /usr/bin/pdflatex
  /usr/bin/pdflatex: symbolic link to pdftex
  

• and pdftex (same behavior as pdflatex):

  $ ls -l /usr/bin/pdftex
  -rwxr-xr-x 1 root root 2115048 Mar 13  2021 /usr/bin/pdftex
  

• or

  $ 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
  

• the following script gives also the same output:

  #!/bin/bash 
  pdflatex $@ 
  

• The original (copied, without any edits) script is as follow:

  #!/bin/bash
  #export PATH=/usr/bin
  #printenv PATH
  pdflatex $@
  #/usr/bin/pdflatex $@
  

  To test the other scripts, I changed the comments and deleted the irrelevant lines in the post here.

• /app/bin does not exist. (/app does not exist)

• I tried to change the PATH in vscode (inside the LaTeX Workshop extensions) since this is most likely the cause for my problem in the first place. However, I could neither fix the problem nor confirm in any way, that my configs (for the LaTeX Workshop extension) had any effect at all.

• when adding the following lines to the script (makeTex.sh is my wrapper script):

  declare -p LD_LIBRARY_PATH 
  declare -p LD_PRELOAD
  

  The outputs are as follows: native Terminal:

  ./makeTex.sh: line 4: declare: LD_LIBRARY_PATH: not found
  ./makeTex.sh: line 5: declare: LD_PRELOAD: not found
  

  vscode Terminal:

  declare -x LD_LIBRARY_PATH="/app/lib"
  ./makeTex.sh: line 5: declare: LD_PRELOAD: not found
  

• The problem occured by using vscode 1.57.1 (installed via flatpak). Other versions of vscode (at least vscodium 1.60.1) do not show the same behavior.

Answer 1

Anecdotally I have experienced a new command not being found after a new package is installed in one overly-configured zsh environment (with oh-my-zsh). I can confirm that this is not the default behavior in zsh. Apparently there is a "cache" of available commands in zsh that can be configured not to auto-refresh.

Some stupid ricer thinks it's wise to guard for that path-on-nfs condition or ram-starved-system condition on a general basis. I dislike oh-my-zsh and all these fancy-prompt styles / configurations that people install and rave about. Fucking hypeware.

I think your question is answered here:

• Rebuild auto-complete index (or whatever it's called) and binaries in $PATH cache in zsh

Make sure you haven't unset the hash_list_all (...)

zstyle ":completion:*:commands" rehash 1

In my case, I can check the above mentioned option by following instructions from this answer:

• zsh: How to check if an option is enabled

$ unsetopt | grep hash; echo ---; setopt | grep hash 
nohashcmds
nohashdirs
hashexecutablesonly
nohashlistall
---

---

Another possibility is that the environment is cleared / initialized not as you expect from the IDE. However, it seems odd that /usr/bin would not be in PATH. Create a new script, run it from the IDE and just print the environment to confirm your assumptions:

env > /tmp/env-in-script-from-ide

Answer 2

Your environment is messed up.

Run the following from the internal terminal and verify the output (you don't have to truncate the path output with head). Use pdflatex instead of gzip, or try with both. If the output is different in your normal terminal and the visual code terminal, it's because the environment is different.

I would guess you installed the visual code via a Snap and that has a limited or isolated environment.

$ 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

In my environment, this works flawlessly. The output is identical in the visual code terminal and in 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

pdflatex

gzip

urxvt

Answer 3

I think the cause are containers, as @polemon suggested in his comment. (for mor informations see: https://www.redhat.com/en/topics/containers/whats-a-linux-container)

This is because I installed vscode via flatpak, which uses a container to run its applications.

Thanks to all, which gave some input and helped to make this a bit clearer.