Jak znaleźć ścieżkę instalacji oprogramowania w systemie Linux?

71

W Linuksie uruchamiam oprogramowanie, pisząc np. Fluidplot. Jak znaleźć ścieżkę instalacji tego oprogramowania?

linux software-installation

— użytkownik5997
źródło

Możliwy duplikat 18472

— sakisk

62

Możesz użyć:

which fluidpoint

aby zobaczyć, skąd jest wykonywany (jeśli znajduje się w zmiennej $ PATH). Lub:

find / -name fluidpoint 2> /dev/null

szukać pliku o nazwie fluipoint i przekierowywać błędy w wirtualnych systemach plików.

Zazwyczaj są one w /sbin, /usr/sbin, /usr/local/binlub ~jak ukrytym katalogu.

Z instrukcji:

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

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

Pełna instrukcja: https://linux.die.net/man/1/which

— n0pe
źródło

4

lub sprawdzić, czy program jest rzeczywiście alias, np alias fluidpoint,

— Czad Feller

2

@Chad Niektóre wersje which(np. Ta wbudowana w ZSH) zrobią to za Ciebie

— Michael Mrozek

@Michael doskonale wiedzieć. Z powodu twojego komentarza właśnie odkryłem, że nowsze wersje bash również to robią. +1 do Twojego komentarza.

— Chad Feller,

Wiersz „Zwykle są ...” jest dość nieuczciwy, dodatkowe oprogramowanie powinno znajdować się w /opt/*lub /usr/local/bin. ~jest twoim katalogiem domowym, nie rozumiem dlaczego nazywasz go „ukrytym”.

— Steve-o

To znaczy, przepraszam, że jestem dwuznaczny ~/.dir. Ukryty katalog znajduje się poniżej katalogu domowego. I zupełnie zapomniałem o /usr/local/bindop.

— n0pe

13

Jeśli używasz dystrybucji opartej na RPM (CentOS, RHEL, SUSE, openSUSE), możesz użyć rpm -ql

Przykład:

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

Rzeczy nie są instalowane w lokalizacjach w świecie Linux / UNIX, tak jak w świecie Windows (a nawet nieco na Macu). Są bardziej rozproszone. Pliki binarne są w /binlub /sbin, biblioteki są w /lib, ikony / grafika / dokumenty są w / share, konfiguracja jest w, /etca dane programu są w /var.

/bin, /lib, /sbinZawierają podstawowych aplikacji potrzebnych do uruchomienia i /usrzawiera wszystkie inne aplikacje użytkownika i systemowe.

— djsumdog
źródło

5

whereisPoleceń lokalizuje binarne, źródłowe i ręcznego strona Pliki do komendy i typepolecenia, co dokładnie mówi powłoka wykonuje po uruchomieniu jakiegoś polecenia.
Spróbuj whereis -l fluidplotw swoim przypadku.

Jeśli zwraca tylko „fluidplot:”, ale nie ma ścieżki, oznacza to, że oprogramowanie nie zostało zainstalowane.

Pamiętaj, że nie obejmuje to plików, które mogą być ukryte w folderze domowym w ~/.local/share/(w moim przypadku).

Znaleziono na Linux Screw

— 魔大农
źródło

Re: „to nie obejmuje ...”, nie jest jasne, czy odnosi się to do typu , whereis , czy obu.

— agc

4

Aby dodać punkt do odpowiedzi @ djsumdog, jeśli używasz dist opartego na DPKG, takiego jak Ubuntu, możesz użyć

dpkg --status some_package

aby sprawdzić, o co chodzi, i

dpkg --listfiles some_package

aby sprawdzić, jakie pliki są dołączone / istotne dla tego pakietu. To jest dla pakietów, które nie mają binarnego do uruchomienia, jak libnss3. I

dpkg --search some_file

aby dowiedzieć się, który pakiet zawiera ten plik.

Na przykład dpkg --listfiles libnss3daje mi:

/.
/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

Pamiętaj, że foldery są własnością nie tylko tych pakietów, ale także innych. Po prostu sprawdź pliki.

I odwrotnie, dpkg --search libnss3.sodaje mi:

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
źródło

0

Zamiast używać which( co prawdopodobnie nie jest właściwym wyborem, chyba że używasz csh ), możesz użyć, command -v fluidplotaby powłoka stała się podobna do powłoki, aby powiedzieć ci, co by zrobił, gdybyś poprosił ją o uruchomienie polecenia ( fluidplotw tym przykładzie) .

Kilka przykładów dla mnie:

$ 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

dzięki czemu można go również użyć do przetestowania, czy polecenie zostanie w ogóle znalezione i spróbuje się uruchomić. Ponieważ większość z nas używa powłok podobnych do Bourne'a (np. Bash lub zsh), często jest to preferowanewhich

— Eric Renouf
źródło