Comment trouver le chemin d'installation d'un logiciel sous Linux?

71

Sous Linux, je lance un logiciel en tapant, par exemple, fluidplot. Comment trouver le chemin d'installation de ce logiciel?

linux software-installation

— utilisateur5997
source

Duplication possible de 18472

— sakisk

62

Vous pouvez utiliser:

which fluidpoint

pour voir où il s’exécute (s’il est dans votre $ PATH). Ou:

find / -name fluidpoint 2> /dev/null

rechercher un fichier nommé fluipoint et rediriger les erreurs sur les systèmes de fichiers virtuels.

Habituellement , ils sont /sbin, /usr/sbin, /usr/local/binou ~comme un répertoire caché.

De Manuel:

NAME
       which - shows the full path of (shell) commands.

SYNOPSIS
       which [options] [--] programname [...]

Manuel complet: https://linux.die.net/man/1/which

— n0pe
source

4

ou vérifiez si le programme est réellement un alias, par exemple alias fluidpoint,

— Chad Feller

2

@Chad Certaines versions de which(par exemple celle intégrée à ZSH) le feront pour vous

— Michael Mrozek

@ Michael excellent à savoir. À cause de votre commentaire, je viens de découvrir que les nouvelles versions de bash le font également. +1 à votre commentaire.

— Chad Feller

La ligne "Habituellement, ils sont ..." est assez trompeuse, un logiciel supplémentaire devrait être inséré /opt/*ou /usr/local/bin. ~est votre répertoire personnel, je ne comprends pas pourquoi vous l’appelez "caché".

— Steve-o

Désolé d'être ambigu, je veux dire ~/.dir. Le répertoire caché est en dessous du répertoire de base. Et j'ai complètement oublié le /usr/local/bindop.

— n0pe

13

Si vous utilisez une distribution basée sur RPM (CentOS, RHEL, SUSE, openSUSE), vous pouvez utiliser rpm -ql

Exemple:

rpm -ql findutils
/bin/find
/usr/bin/find
/usr/bin/xargs
/usr/share/doc/packages/findutils
/usr/share/doc/packages/findutils/AUTHORS
/usr/share/doc/packages/findutils/COPYING
/usr/share/doc/packages/findutils/NEWS
/usr/share/doc/packages/findutils/README
/usr/share/doc/packages/findutils/THANKS
/usr/share/doc/packages/findutils/TODO
/usr/share/info/find.info.gz
/usr/share/man/man1/find.1.gz

Les choses ne sont pas installées à des emplacements dans le monde Linux / UNIX comme dans le monde Windows (et même un peu dans le Mac). Ils sont plus distribués. Les binaires sont dans /binou /sbin, les bibliothèques sont dans /lib, les icônes / graphiques / docs sont dans / share, la configuration est dans /etcet les données de programme sont dans /var.

Le /bin, /lib, /sbincontiennent les applications de base nécessaires pour le démarrage et la /usrcontient toutes les autres applications de l' utilisateur et le système.

— djsumdog
source

5

La whereiscommande localise les fichiers binaire, source et manuel pour une commande, et typeindique ce que le shell exécute exactement lorsque vous exécutez une certaine commande.
Essayez whereis -l fluidplotdans votre cas.

S'il ne renvoie que "fluidplot:", mais pas de chemin, cela signifie que le logiciel n'est pas installé.

Notez que cela n'inclut pas les fichiers qui peuvent être cachés dans le dossier de départ sous ~/.local/share/(dans mon cas).

Trouvé sur la vis Linux

— 大农
source

Re: « cela ne comprend pas ... », on ne sait pas si cela fait référence à taper , whereis , ou les deux.

— agc

4

Juste pour ajouter un point à la réponse de @ djsumdog, si vous utilisez une distribution basée sur DPKG, comme Ubuntu, vous pouvez utiliser

dpkg --status some_package

pour vérifier de quoi il s'agit, et

dpkg --listfiles some_package

vérifier quels fichiers sont inclus / pertinents pour ce paquet. C'est pour les paquets qui n'ont pas de binaire à exécuter, comme libnss3. Et

dpkg --search some_file

pour trouver quel paquet contient ce fichier.

Par exemple, dpkg --listfiles libnss3me donne:

/.
/usr
/usr/lib
/usr/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu/libssl3.so
/usr/lib/i386-linux-gnu/nss
/usr/lib/i386-linux-gnu/nss/libsoftokn3.chk
/usr/lib/i386-linux-gnu/nss/libnssckbi.so
/usr/lib/i386-linux-gnu/nss/libnsssysinit.so
/usr/lib/i386-linux-gnu/nss/libfreebl3.chk
/usr/lib/i386-linux-gnu/nss/libnssdbm3.chk
/usr/lib/i386-linux-gnu/nss/libnssdbm3.so
/usr/lib/i386-linux-gnu/nss/libsoftokn3.so
/usr/lib/i386-linux-gnu/nss/libfreebl3.so
/usr/lib/i386-linux-gnu/libnssutil3.so
/usr/lib/i386-linux-gnu/libsmime3.so
/usr/lib/i386-linux-gnu/libnss3.so
/usr/share
/usr/share/doc
/usr/share/doc/libnss3
/usr/share/doc/libnss3/copyright
/usr/share/doc/libnss3/changelog.Debian.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libnss3

Notez que les dossiers ne sont pas seulement la propriété de ces packages, mais également des autres. Il suffit de vérifier les fichiers.

Et inversement, dpkg --search libnss3.some donne:

firefox: /usr/lib/firefox/libnss3.so
thunderbird: /usr/lib/thunderbird/libnss3.so
libnss3:i386: /usr/lib/i386-linux-gnu/libnss3.so
libnss3-1d:i386: /usr/lib/i386-linux-gnu/libnss3.so.1d

— WesternGun
source

0

Au lieu d’utiliser which( ce qui n’est probablement pas le bon choix si vous n’utilisez pas csh ), vous pouvez utiliser command -v fluidplotle shell pour qu’il puisse vous dire ce qu’il ferait si vous lui demandiez d’exécuter la commande ( fluidplotdans cet exemple). .

Quelques exemples pour moi:

$ command -v ls
alias ls='ls --color=auto'
$ command -v cat
/bin/cat
$ test_func() {
> :
> }
$ command -v test_func
test_func
$ which test_func
/usr/bin/which: no test_func in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin)
$ if command -v noSuchFile; then echo "It exists"; else echo "does not exist"; fi
does not exist

vous pouvez donc également l'utiliser pour vérifier si une commande peut même être trouvée et tentée de s'exécuter. Comme la plupart d’entre nous utilisons des coquilles de type Bourne (par exemple, bash ou zsh), cela est souvent préférable àwhich

— Eric Renouf
source