1

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.

11
  • maybe vscode use chrooted environment?
    – K-att-
    Sep 21 at 11:01
  • 2
    Please edit your question and include the information from the comments above. Also tell us what Linux you are using, it might be relevant. Oh, and also try running a script with just ls or /usr/bin/ls, does that work? Finally, what is the output of ls -l usr/bin/pdflatex?
    – terdon
    Sep 21 at 13:49
  • 2
    (1) Unquoted $@ is not what you want when writing a wrapper script; you want "$@". This is irrelevant to the issue though. (2) In the script invoke env or declare -p. Does the output mention LD_LIBRARY_PATH or LD_PRELOAD? Sep 21 at 21:50
  • 1
    There are many moving pieces (LD_LIBRARY_PATH, etc). I suggest you try to debug it instead of guessing your way around it. Start that vscode via strace -o strace-log -vfe trace=execve /path/to/vscode and see what program it's actually trying to run and how.
    – zevzek
    Sep 22 at 5:45
  • 1
    Did you install VSCode from flathub? If you do, it's containerized. I'm saying this, because you mention /app which is often used with containers.
    – polemon
    Sep 24 at 5:52
0

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:

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:

$ 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
1
  • I don't think, that either of these possibilities is correct: For the first one: I have tried calling the script from bash (with auto-completion) and sh (without auto-completion) with the same result. This would mean, that the auto-completion feature, and therefore the cache for it, have no affect. And for the second one: This is not correct, /usr/bin is in the PATH.
    – flobue
    Sep 22 at 18:48
0

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 pdflatex

gzip gzip

urxvt enter image description here

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.