Jak mogę sprawdzić, czy program istnieje ze skryptu Bash?

Jak sprawdziłbym, czy program istnieje, w taki sposób, że zwróci błąd i zakończy działanie lub kontynuuje działanie skryptu?

Wygląda na to, że powinno to być łatwe, ale to mnie dręczy.

Odpowiedź

Kompatybilny z POSIX:

command -v <the_command>

W środowiskach specyficznych dla Bash:

hash <the_command> # For regular commands. Or...
type <the_command> # To check built-ins and keywords

Wyjaśnienie

Unikać which. Nie tylko jest to proces zewnętrznego jesteś uruchomienie za to bardzo niewiele (czyli builtins podoba hash, typeczy commandto sposób tańszy), można również liczyć na builtins faktycznie zrobić to, co chcesz, a skutki poleceń zewnętrznych można łatwo zmieniać z system do systemu.

Dlaczego to obchodzi?

• Wiele systemów operacyjnych ma taki which, który nawet nie ustawia statusu wyjścia , co oznacza, że if which foonawet tam nie zadziała i zawsze będzie raportował, że fooistnieje, nawet jeśli nie (zauważ, że niektóre powłoki POSIX też to robią hash).
• Wiele systemów operacyjnych whichrobi niestandardowe i złe rzeczy, takie jak zmiana danych wyjściowych, a nawet podłączanie się do menedżera pakietów.

Więc nie używaj which. Zamiast tego użyj jednego z tych:

$ command -v foo >/dev/null 2>&1 || { echo >&2 "I require foo but it's not installed.  Aborting."; exit 1; }
$ type foo >/dev/null 2>&1 || { echo >&2 "I require foo but it's not installed.  Aborting."; exit 1; }
$ hash foo 2>/dev/null || { echo >&2 "I require foo but it's not installed.  Aborting."; exit 1; }

(Drobna uwaga: niektórzy sugerują, że 2>&-jest taka sama, 2>/dev/nullale krótsza - to nieprawda . 2>&-Zamyka FD 2, co powoduje błąd w programie, gdy próbuje pisać do stderr, co bardzo różni się od pomyślnego zapisu do niego i odrzucenia wyniku (i niebezpieczne!))

Jeśli masz hash bang /bin/sh, powinieneś się przejmować tym, co mówi POSIX. typei hashkody wyjścia nie są zbyt dobrze zdefiniowane przez POSIX, i hashwidać, że kończy się pomyślnie, gdy polecenie nie istnieje (jeszcze tego nie widziałem type). commandStatus wyjścia jest dobrze zdefiniowany przez POSIX, więc prawdopodobnie jest on najbezpieczniejszy w użyciu.

Jeśli twoje zastosowania skryptów bashchociaż, reguły POSIX nie naprawdę już sprawa i obie typei hashstają się całkowicie bezpieczne do użycia. typema teraz -Pdo przeszukania PATHi hashma taki efekt uboczny, że lokalizacja polecenia zostanie zakodowana (w celu szybszego wyszukiwania przy następnym użyciu), co zwykle jest dobrą rzeczą, ponieważ prawdopodobnie sprawdza się jej istnienie w celu faktycznego użycia .

Jako prosty przykład, oto funkcja, która działa, gdatejeśli istnieje, w przeciwnym razie date:

gnudate() {
    if hash gdate 2>/dev/null; then
        gdate "$@"
    else
        date "$@"
    fi
}

Poniżej przedstawiono przenośny sposób sprawdzenia, czy polecenie istnieje $PATH i jest wykonywalne:

[ -x "$(command -v foo)" ]

Przykład:

if ! [ -x "$(command -v git)" ]; then
  echo 'Error: git is not installed.' >&2
  exit 1
fi

Sprawdzanie wykonywalności jest potrzebne, ponieważ bash zwraca plik niewykonywalny, jeśli nie znaleziono pliku wykonywalnego o takiej nazwie $PATH.

Zauważ również, że jeśli plik wykonywalny o tej samej nazwie co plik wykonywalny istnieje wcześniej $PATH, dash zwraca to pierwsze, nawet jeśli to drugie zostanie wykonane. Jest to błąd i jest niezgodny ze standardem POSIX. [ Raport o błędzie ] [ Standard ]

Ponadto nie powiedzie się, jeśli szukane polecenie zostało zdefiniowane jako alias.

Zgadzam się z lhunath, aby zniechęcać do korzystania z niego which, a jego rozwiązanie jest całkowicie poprawne dla użytkowników Bash . Aby jednak być bardziej przenośnym, command -vnależy zastosować zamiast tego:

$ command -v foo >/dev/null 2>&1 || { echo "I require foo but it's not installed.  Aborting." >&2; exit 1; }

Polecenie commandjest zgodne z POSIX. Zobacz jego specyfikację: polecenie - wykonaj proste polecenie

Uwaga: typejest zgodny z POSIX, ale type -Pnie jest.

Mam funkcję zdefiniowaną w moim .bashrc, która ułatwia to.

command_exists () {
    type "$1" &> /dev/null ;
}

Oto przykład, w jaki sposób jest używany (od mojego .bash_profile.)

if command_exists mvim ; then
    export VISUAL="mvim --nofork"
fi

Zależy to od tego, czy chcesz wiedzieć, czy istnieje ona w jednym z katalogów $PATHzmiennej, czy też znasz jej absolutne położenie. Jeśli chcesz wiedzieć, czy jest w $PATHzmiennej, użyj

if which programname >/dev/null; then
    echo exists
else
    echo does not exist
fi

w przeciwnym razie użyj

if [ -x /path/to/programname ]; then
    echo exists
else
    echo does not exist
fi

Przekierowanie do /dev/null/w pierwszym przykładzie tłumi dane wyjściowe whichprogramu.

Rozwijając odpowiedzi @ lhunath i @ GregV, oto kod dla osób, które chcą łatwo umieścić tę kontrolę w ifinstrukcji:

exists()
{
  command -v "$1" >/dev/null 2>&1
}

Oto jak go użyć:

if exists bash; then
  echo 'Bash exists!'
else
  echo 'Your system does not have Bash'
fi

Spróbuj użyć:

test -x filename

lub

[ -x filename ]

Z strony podręcznika Bash w sekcji Wyrażenia warunkowe :

 -x file
          True if file exists and is executable.

Aby użyć hash, jak sugeruje @lhunath , w skrypcie Bash:

hash foo &> /dev/null
if [ $? -eq 1 ]; then
    echo >&2 "foo not found."
fi

Ten skrypt jest uruchamiany, hasha następnie sprawdza, czy kod wyjścia najnowszej komendy, przechowywana w wartości $?, jest równy 1. Jeśli hashnie znajdzie foo, kod wyjścia będzie 1. Jeśli foojest obecny, kod zakończenia będzie następujący 0.

&> /dev/nullprzekierowuje standardowy błąd i standardowe wyjście z, hashaby nie pojawił się na ekranie i echo >&2zapisuje komunikat do standardowego błędu.

Nigdy nie dostałem poprzednich odpowiedzi do pracy na polu, do którego mam dostęp. Po pierwsze, typezostał zainstalowany (robi to, co morerobi). Potrzebna jest więc wbudowana dyrektywa. To polecenie działa dla mnie:

if [ `builtin type -p vim` ]; then echo "TRUE"; else echo "FALSE"; fi

Sprawdź wiele zależności i poinformuj użytkowników końcowych o stanie

for cmd in latex pandoc; do
  printf '%-10s' "$cmd"
  if hash "$cmd" 2>/dev/null; then
    echo OK
  else
    echo missing
  fi
done

Przykładowe dane wyjściowe:

latex     OK
pandoc    missing

Ustaw 10maksymalną długość polecenia. Nie jest to automatyczne, ponieważ nie widzę nieokreślonego sposobu POSIX: Jak wyrównać kolumny tabeli oddzielonej spacjami w Bash?

Sprawdź, czy niektóre aptpakiety są zainstalowane dpkg -si zainstaluj je w inny sposób .

Zobacz: Sprawdź, czy pakiet apt-get jest zainstalowany, a następnie zainstaluj go, jeśli nie jest on w systemie Linux

Zostało to wcześniej wspomniane na stronie: Jak mogę sprawdzić, czy program istnieje ze skryptu Bash?

Jeśli sprawdzisz istnienie programu, prawdopodobnie i tak będziesz go później uruchamiał. Dlaczego nie spróbować uruchomić go w pierwszej kolejności?

if foo --version >/dev/null 2>&1; then
    echo Found
else
    echo Not found
fi

Jest to bardziej godne zaufania sprawdzenie, czy program działa, niż tylko patrzenie na katalogi PATH i uprawnienia do plików.

Dodatkowo możesz uzyskać użyteczne wyniki ze swojego programu, takie jak jego wersja.

Oczywiście wady polegają na tym, że niektóre programy mogą być trudne do uruchomienia, a niektóre nie mają --versionopcji natychmiastowego (i pomyślnego) wyjścia.

hash foo 2>/dev/null: działa z powłoką Z (Zsh), Bash, Dash i ash .

type -p foo: wygląda na to, że działa z powłoką Z, Bash i ash ( BusyBox ), ale nie Dash (interpretuje to -pjako argument).

command -v foo: działa z powłoką Z, Bash, Dash, ale nie ash (BusyBox) ( -ash: command: not found).

Należy również pamiętać, że builtinnie jest dostępny z Ash i Dash.

Użyj wbudowanych Bash, jeśli możesz:

which programname

...

type -P programname

Polecenie -vdziała poprawnie, jeśli dla testu jest ustawiona opcja POSIX_BUILTINS <command>, ale może się nie powieść, jeśli nie. (To działało dla mnie od lat, ale ostatnio wpadłem na takie, w którym nie działało).

Uważam, że następujące elementy są bardziej odporne na awarie:

test -x $(which <command>)

Ponieważ testuje trzy rzeczy: ścieżkę, istnienie i pozwolenie na wykonanie.

Dla zainteresowanych żadna z metodologii z poprzednich odpowiedzi nie działa, jeśli chcesz wykryć zainstalowaną bibliotekę. Wyobrażam sobie, że możesz albo fizycznie sprawdzić ścieżkę (potencjalnie dla plików nagłówkowych itp.), Albo coś takiego (jeśli korzystasz z dystrybucji opartej na Debianie):

dpkg --status libdb-dev | grep -q not-installed

if [ $? -eq 0 ]; then
    apt-get install libdb-dev
fi

Jak widać z powyższego, odpowiedź „0” z zapytania oznacza, że ​​pakiet nie został zainstalowany. Jest to funkcja „grep” - „0” oznacza, że ​​znaleziono dopasowanie, „1” oznacza, że ​​nie znaleziono dopasowania.

Jest tu mnóstwo opcji, ale nie zdziwiłem się, że nie ma szybkich jedno-linijek. Oto, czego użyłem na początku moich skryptów:

[[ "$(command -v mvn)" ]] || { echo "mvn is not installed" 1>&2 ; exit 1; }
[[ "$(command -v java)" ]] || { echo "java is not installed" 1>&2 ; exit 1; }

Jest to oparte na wybranej tutaj odpowiedzi i innym źródle.

Powiedziałbym, że nie ma żadnego przenośnego i w 100% niezawodnego sposobu z powodu wiszących aliases. Na przykład:

alias john='ls --color'
alias paul='george -F'
alias george='ls -h'
alias ringo=/

Oczywiście tylko ostatni jest problematyczny (bez obrazy dla Ringo!). Ale wszystkie z nich są ważne aliasz punktu widzenia command -v.

Aby odrzucić takie wiszące ringo, musimy przeanalizować dane wyjściowe wbudowanego aliaspolecenia powłoki i powtórzyć je w nich ( command -vnie jest to coś lepszego niż aliastutaj.) Nie ma dla niego żadnego przenośnego rozwiązania, a nawet Bash- konkretne rozwiązanie jest dość nużące.

Pamiętaj, że takie rozwiązanie bezwarunkowo odrzuci alias ls='ls -F':

test() { command -v $1 | grep -qv alias }

Poinformuje zgodnie z lokalizacją, czy program istnieje, czy nie:

    if [ -x /usr/bin/yum ]; then
        echo "This is Centos"
    fi

whichKomenda może być użyteczna. człowiek który

Zwraca 0, jeśli plik wykonywalny został znaleziony, i zwraca 1, jeśli nie został znaleziony lub nie jest wykonywalny:

NAME

       which - locate a command

SYNOPSIS

       which [-a] filename ...

DESCRIPTION

       which returns the pathnames of the files which would
       be executed in the current environment, had its
       arguments been given as commands in a strictly
       POSIX-conformant shell. It does this by searching
       the PATH for executable files matching the names
       of the arguments.

OPTIONS

       -a     print all matching pathnames of each argument

EXIT STATUS

       0      if all specified commands are 
              found and executable

       1      if one or more specified commands is nonexistent
              or not executable

       2      if an invalid option is specified

Zaletą whichjest to, że dowiaduje się, czy plik wykonywalny jest dostępny w uruchomionym środowisku which- oszczędza to kilka problemów ...

Moja konfiguracja dla serwera Debian :

Miałem problem, gdy wiele pakietów zawierało tę samą nazwę.

Na przykład apache2. To było moje rozwiązanie:

function _apt_install() {
    apt-get install -y $1 > /dev/null
}

function _apt_install_norecommends() {
    apt-get install -y --no-install-recommends $1 > /dev/null
}
function _apt_available() {
    if [ `apt-cache search $1 | grep -o "$1" | uniq | wc -l` = "1" ]; then
        echo "Package is available : $1"
        PACKAGE_INSTALL="1"
    else
        echo "Package $1 is NOT available for install"
        echo  "We can not continue without this package..."
        echo  "Exitting now.."
        exit 0
    fi
}
function _package_install {
    _apt_available $1
    if [ "${PACKAGE_INSTALL}" = "1" ]; then
        if [ "$(dpkg-query -l $1 | tail -n1 | cut -c1-2)" = "ii" ]; then
             echo  "package is already_installed: $1"
        else
            echo  "installing package : $1, please wait.."
            _apt_install $1
            sleep 0.5
        fi
    fi
}

function _package_install_no_recommends {
    _apt_available $1
    if [ "${PACKAGE_INSTALL}" = "1" ]; then
        if [ "$(dpkg-query -l $1 | tail -n1 | cut -c1-2)" = "ii" ]; then
             echo  "package is already_installed: $1"
        else
            echo  "installing package : $1, please wait.."
            _apt_install_norecommends $1
            sleep 0.5
        fi
    fi
}

Jeśli chłopaki / dziewczęta nie potraficie znaleźć odpowiedzi na te pytania i wyciągacie włosy z pleców, spróbujcie uruchomić to samo polecenie bash -c. Spójrz tylko na to somnambularne majaczenie. Oto, co naprawdę dzieje się po uruchomieniu $ (podkomenda):

Pierwszy. Może dać zupełnie inną wydajność.

$ command -v ls
alias ls='ls --color=auto'
$ bash -c "command -v ls"
/bin/ls

Druga. Może w ogóle nie dać żadnych wyników.

$ command -v nvm
nvm
$ bash -c "command -v nvm"
$ bash -c "nvm --help"
bash: nvm: command not found

Wariant skrótu ma jedną pułapkę: w wierszu poleceń możesz na przykład wpisać

one_folder/process

wykonać proces. W tym celu folder nadrzędny one_folder musi znajdować się w $ PATH . Ale gdy spróbujesz zaszyfrować to polecenie, zawsze się powiedzie:

hash one_folder/process; echo $? # will always output '0'

Po drugie używam „command -v”. Np. Tak:

md=$(command -v mkdirhier) ; alias md=${md:=mkdir}  # bash

emacs="$(command -v emacs) -nw" || emacs=nano
alias e=$emacs
[[ -z $(command -v jed) ]] && alias jed=$emacs

Musiałem sprawdzić, czy Git został zainstalowany w ramach wdrażania naszego serwera CI . Mój ostatni skrypt Bash był następujący (serwer Ubuntu):

if ! builtin type -p git &>/dev/null; then
  sudo apt-get -y install git-core
fi

Aby naśladować Basha type -P cmd, możemy użyć zgodności z POSIX env -i type cmd 1>/dev/null 2>&1.

man env
# "The option '-i' causes env to completely ignore the environment it inherits."
# In other words, there are no aliases or functions to be looked up by the type command.

ls() { echo 'Hello, world!'; }

ls
type ls
env -i type ls

cmd=ls
cmd=lsx
env -i type $cmd 1>/dev/null 2>&1 || { echo "$cmd not found"; exit 1; }

Jeśli nie ma żadnych zewnętrznych type polecenia dostępne (jak za pewnik tutaj ), możemy użyć zgodny z POSIX env -i sh -c 'type cmd 1>/dev/null 2>&1':

# Portable version of Bash's type -P cmd (without output on stdout)
typep() {
   command -p env -i PATH="$PATH" sh -c '
      export LC_ALL=C LANG=C
      cmd="$1"
      cmd="`type "$cmd" 2>/dev/null || { echo "error: command $cmd not found; exiting ..." 1>&2; exit 1; }`"
      [ $? != 0 ] && exit 1
      case "$cmd" in
        *\ /*) exit 0;;
            *) printf "%s\n" "error: $cmd" 1>&2; exit 1;;
      esac
   ' _ "$1" || exit 1
}

# Get your standard $PATH value
#PATH="$(command -p getconf PATH)"
typep ls
typep builtin
typep ls-temp

Przynajmniej w systemie Mac OS X 10.6.8 (Snow Leopard) używającym wersji Bash 4.2.24 (2) command -v lsnie pasuje do przeniesionego/bin/ls-temp .

W przypadku, gdy chcesz sprawdzić, czy program istnieje i jest naprawdę program, a nie atakujących wbudowane polecenie , a następnie command, typei hashnie są odpowiednie do testowania jak oni wszyscy powrotu 0 status wyjścia dla wbudowanych komend.

Na przykład, nie ma czasu program, który dysponuje więcej ofert niż raz wbudowanego polecenia. Aby sprawdzić, czy program istnieje, sugeruję użycie whichjak w poniższym przykładzie:

# First check if the time program exists
timeProg=`which time`
if [ "$timeProg" = "" ]
then
  echo "The time program does not exist on this system."
  exit 1
fi

# Invoke the time program
$timeProg --quiet -o result.txt -f "%S %U + p" du -sk ~
echo "Total CPU time: `dc -f result.txt` seconds"
rm result.txt

Scenariusz

#!/bin/bash

# Commands found in the hash table are checked for existence before being
# executed and non-existence forces a normal PATH search.
shopt -s checkhash

function exists() {
 local mycomm=$1; shift || return 1

 hash $mycomm 2>/dev/null || \
 printf "\xe2\x9c\x98 [ABRT]: $mycomm: command does not exist\n"; return 1;
}
readonly -f exists

exists notacmd
exists bash
hash
bash -c 'printf "Fin.\n"'

Wynik

✘ [ABRT]: notacmd: command does not exist
hits    command
   0    /usr/bin/bash
Fin.

Używam tego, ponieważ jest to bardzo łatwe:

if [ `LANG=C type example 2>/dev/null|wc -l` = 1 ];then echo exists;else echo "not exists";fi

lub

if [ `LANG=C type example 2>/dev/null|wc -l` = 1 ];then
echo exists
else echo "not exists"
fi

Wykorzystuje wbudowane powłoki i status echa programów do standardowego wyjścia i nic do standardowego błędu. Z drugiej strony, jeśli polecenie nie zostanie znalezione, wyświetla status echa tylko do standardowego błędu.

Zakładając, że przestrzegasz już bezpiecznych praktyk powłoki :

set -eu -o pipefail
shopt -s failglob

./dummy --version 2>&1 >/dev/null

Zakłada się, że polecenie można wywołać w taki sposób, że nie robi (prawie) nic, na przykład zgłasza swoją wersję lub wyświetla pomoc.

Jeśli dummypolecenie nie zostanie znalezione, Bash kończy działanie z następującym błędem ...

./my-script: line 8: dummy: command not found

Jest to bardziej przydatne i mniej szczegółowe niż inne command -v(i podobne) odpowiedzi, ponieważ komunikat o błędzie jest generowany automatycznie i zawiera również odpowiedni numer wiersza.