Почему бы не использовать “который”? Что тогда использовать?

Когда вы ищете путь к исполняемому файлу или проверяете, что произойдет, если вы введете имя команды в оболочке Unix, существует множество различных утилит (which, type, command, whence, where, whereis, whatis, hash и т. д.).

Мы часто слышим, что which следует избегать. Почему? Что мы можем использовать вместо этого?

Вот вся информация, о которой вы никогда не думали, что не захотите знать:

Резюме

Чтобы получить путь к исполняемому файлу в сценарии оболочки, подобной Bourne (есть несколько оговорок; см. ниже):

ls_path=$(command -v ls)

Чтобы узнать, существует ли указанная команда:

if command -v given-command > /dev/null; then
  echo given-command доступна
else
  echo given-command не доступна
fi

В командной строке интерактивной оболочки, подобной Bourne:

type ls

Команда which является сломанным наследием от C-Shell и лучше оставить в покое в оболочках, подобных Bourne.

Сценарии использования

Существует различие между поиском этой информации как частью сценария или интерактивно в командной строке.

В командной строке, типичный сценарий использования: эта команда ведет себя странно, использую ли я правильную? Что на самом деле произошло, когда я набрал mycmd? Могу ли я узнать больше о том, что это?

В этом случае вы хотите знать, что ваша оболочка делает, когда вы вызываете команду, не вызывая саму команду.

В сценариях оболочки, это, как правило, совершенно другое. В сценарии оболочки нет причины, по которой вы хотите знать, где или что представляет собой команда, если все, что вам нужно сделать, это запустить ее. В общем, то, что вы хотите знать, это путь к исполняемому файлу, чтобы получить больше информации о нем (например, путь к другому файлу относительно этого, или прочитать информацию из содержимого исполняемого файла по этому пути).

Интерактивно вы можете захотеть узнать о всех командах my-cmd, доступных в системе, в сценариях это редко требуется.

Большинство доступных инструментов (как это часто бывает) были разработаны для интерактивного использования.

История

Сначала немного истории.

Ранние Unix оболочки до конца 70-х не имели функций или псевдонимов. Только традиционный поиск исполняемых файлов в $PATH. csh ввела псевдонимы около 1978 года (хотя csh была впервые выпущена в 2BSD, в мае 1979 года) и также обработку .cshrc для пользователей, чтобы настроить оболочку (каждая оболочка, такая как csh, читает .cshrc, даже когда она не интерактивная, например, в сценариях).

Хотя оболочка Bourne была впервые выпущена в Unix V7 ранее в 1979 году, поддержка функций была добавлена гораздо позже (1984 году в SVR2), и у нее никогда не было какого-либо rc файла (файл .profile предназначен для настройки вашей среды, а не для оболочки пер se).

csh стала гораздо более популярной, чем оболочка Bourne, так как (хотя у нее был ужасно худший синтаксис, чем у оболочки Bourne) она добавила много более удобных и приятных функций для интерактивного использования.

В 3BSD (1980) был добавлен which csh скрипт для пользователей csh, чтобы помочь идентифицировать исполняемые файлы, и это на самом деле не сильно отличается от скрипта, который вы можете найти как which на многих коммерческих Unix системах сегодня (таких как Solaris, HP/UX, AIX или Tru64).

Этот скрипт читает ~/.cshrc пользователя (как делают все скрипты csh, если они не вызываются с csh -f) и ищет указанные имена команд в списке псевдонимов и в $path (массив, который csh поддерживает на основе $PATH).

Вот как дела обстоят: which пришел первым для самой популярной оболочки в то время (и csh оставалась популярной до середины 90-х), что является основной причиной, почему он был задокументирован в книгах и по-прежнему широко используется.

Обратите внимание, что даже для пользователя csh этот which csh скрипт не обязательно предоставит вам правильную информацию. Он получает псевдонимы, определенные в ~/.cshrc, а не те, которые вы могли определить позже в командной строке или, например, вызвав другой файл csh с помощью source, и (хотя это было бы не очень хорошей идеей) PATH может быть переопределен в ~/.cshrc.

Выполнение этой команды which из оболочки Bourne все еще будет искать псевдонимы, определенные в вашем ~/.cshrc, но если у вас его нет, потому что вы не используете csh, это все равно, вероятно, даст вам правильный ответ.

Подобная функциональность не была добавлена в оболочку Bourne до 1984 года в SVR2 с помощью встроенной команды type. Тот факт, что она встроенная (в отличие от внешнего скрипта), означает, что она может дать вам правильную информацию (в какой-то степени), поскольку у нее есть доступ к внутреннему устройству оболочки.

$ print -r -- =ls
/bin/ls
$ cmd=ls; print -r -- $cmd:c
/bin/ls

$ print -r -- $commands[ls]
/bin/ls

ls_path=$(command -v ls)

if command -v given-command > /dev/null 2>&1; then
  echo given-command доступна
else
  echo given-command не доступна
fi

echo_path=$(which echo)

env echo это не выводится встроенной командой echo

set echo_path = "`env which echo`"

$ perl -le 'print system "command -v emacs"'
-1
$ perl -le 'print system ":;command -v emacs"'
/usr/bin/emacs
0

$ perl -e 'print `command -v emacs`'
$ perl -e 'print `:;command -v emacs`'
/usr/bin/emacs

Причины, по которым может не стоить использовать which, уже были объяснены, но вот несколько примеров на нескольких системах, где which на самом деле дает сбой.

В оболочках, подобных Bourne, мы сравниваем вывод which с выводом type (type является встроенной командой оболочки, она должна быть истиной, так как это оболочка, рассказывающая нам, как она вызовет команду).

Многие случаи являются крайними случаями, но имейте в виду, что which/type часто используются в крайних случаях (чтобы найти ответ на неожиданное поведение, например: почему эта команда ведет себя так, какую же я вызываю?).

Большинство систем, большинство оболочек, подобных Bourne: функции

Самый очевидный случай — это функции:

$ type ls
ls is a function
ls ()
{
[ -t 1 ] && set -- -F "$@";
command ls "$@"
}
$ which ls
/bin/ls

Причина заключается в том, что which сообщает только об исполняемых файлах, а иногда и о псевдонимах (хотя не всегда о тех, что в вашей оболочке), а не о функциях.

Страница man GNU which имеет сломанный (так как они забыли заключить $@ в кавычки) пример о том, как использовать его для отчета о функциях, но, как и в случае с псевдонимами, поскольку он не реализует парсер синтаксиса оболочки, его легко обмануть:

$ which() { (alias; declare -f) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@";}
$ f() { echo $'\n}\ng ()\n{ echo bar;\n}\n' >> ~/foo; }
$ type f
f is a function
f ()
{
echo '
}
g ()
{ echo bar;
}
' >> ~/foo
}
$ type g
bash: type: g: not found
$ which f
f ()
{
echo '
}
$ which g
g ()
{ echo bar;
}

Большинство систем, большинство оболочек, подобных Bourne: встроенные команды

Другой очевидный случай — это встроенные команды или ключевые слова, так как which, будучи внешней командой, не имеет никакой возможности знать, какие встроенные команды имеются в вашей оболочке (и некоторые оболочки, такие как zsh, bash или ksh, могут загружать встроенные команды динамически):

$ type echo . time
echo is a shell builtin
. is a shell builtin
time is a shell keyword
$ which echo . time
/bin/echo
which: no . in (/bin:/usr/bin)
/usr/bin/time

(это не касается zsh, где which является встроенной)

Solaris 10, AIX 7.1, HP/UX 11i, Tru64 5.1 и многие другие:

$ csh
% which ls
ls:   aliased to ls -F
% unalias ls
% which ls
ls:   aliased to ls -F
% ksh
$ which ls
ls:   aliased to ls -F
$ type ls
ls is a tracked alias for /usr/bin/ls

Это происходит потому, что во многих коммерческих Unix системах which (как в оригинальной реализации в 3BSD) является csh скриптом, который читает ~/.cshrc.
Псевдонимы, которые он будет сообщать, — это те, что определены там, независимо от текущих определенных псевдонимов и независимо от модели оболочки, которую вы используете.

В HP/UX или Tru64:

% echo 'setenv PATH /bin:/usr/bin' >> ~/.cshrc
% setenv PATH ~/bin:/bin:/usr/bin
% ln -s /bin/ls ~/bin/
% which ls
/bin/ls

(версии Solaris и AIX исправили эту проблему, сохраняя $path перед чтением ~/.cshrc и восстанавливая его перед поиском команд)

$ type 'a b'
a b is /home/stephane/bin/a b
$ which 'a b'
no a in /usr/sbin /usr/bin
no b in /usr/sbin /usr/bin

Или:

$ d="$HOME/my bin"
$ mkdir "$d"; PATH=$PATH:$d
$ ln -s /bin/ls "$d/myls"
$ type myls
myls is /home/stephane/my bin/myls
$ which myls
no myls in /usr/sbin /usr/bin /home/stephane/my bin

(конечно, будучи скриптом csh, вы не можете ожидать, что он будет работать с аргументами, содержащими пробелы…)

CentOS 6.4, bash

$ type which
which is aliased to `alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
$ alias foo=': "|test|"'
$ which foo
alias foo=': "|test|"'
        /usr/bin/test
$ alias $'foo=\nalias bar="
$ unalias bar
-bash: unalias: bar: not found
$ which bar
alias bar="

На этой системе есть псевдоним, определенный на уровне системы, который оборачивает команду GNU which.

Ложный вывод вызван тем, что which читает вывод bash‘s alias, но не знает, как правильно его разобрать, и использует эвристику (один псевдоним на строку, ищет первую найденную команду после |, ;, &…)

Худшее в CentOS заключается в том, что zsh имеет совершенно нормальную встроенную команду which, но CentOS смогла сломать ее, заменив на неработающий псевдоним для GNU which.

Debian 7.0, ksh93:

(хотя это относится к большинству систем с множеством оболочек)

$ unset PATH
$ which which
/usr/local/bin/which
$ type which
which is a tracked alias for /bin/which

На Debian /bin/which является скриптом /bin/sh. В моем случае sh — это dash, но это то же самое, когда это bash.

Неустановленный PATH не предназначен для отключения поиска PATH, а означает использование умолчательного пути системы, который, к сожалению, на Debian никто не согласен (dash и bash имеют /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, zsh имеет /bin:/usr/bin:/usr/ucb:/usr/local/bin, ksh93 имеет /bin:/usr/bin, mksh имеет /usr/bin:/bin ($(getconf PATH)), execvp() (как в env) имеет :/bin:/usr/bin (да, сначала смотрит в текущем каталоге!)).

Вот почему which дает неверный результат выше, так как он использует dash‘s умолчательный PATH, который отличается от ksh93.

С GNU which дела обстоят не лучше, он сообщает:

which: no which in ((null))

(что любопытно, в моей системе действительно есть /usr/local/bin/which, который на самом деле является akanga скриптом, поставляемым с akanga (производной оболочкой rc, где умолчательный PATH — /usr/ucb:/usr/bin:/bin:.))

bash, любая система:

Тот самый пример, который упоминает Крис в своем ответе:

$ PATH=$HOME/bin:/bin
$ ls /dev/null
/dev/null
$ cp /bin/ls bin
$ type ls
ls is hashed (/bin/ls)
$ command -v ls
/bin/ls
$ which ls
/home/chazelas/bin/ls

Также после вызова hash вручную:

$ type -a which
which is /usr/local/bin/which
which is /usr/bin/which
which is /bin/which
$ hash -p /bin/which which
$ which which
/usr/local/bin/which
$ type which
which is hashed (/bin/which)

Теперь случай, когда which и иногда type дают сбой:

$ mkdir a b
$ echo '#!/bin/echo' > a/foo
$ echo '#!/' > b/foo
$ chmod +x a/foo b/foo
$ PATH=b:a:$PATH
$ which foo
b/foo
$ type foo
foo is b/foo

Теперь с некоторыми оболочками:

$ foo
bash: ./b/foo: /: bad interpreter: Permission denied

С другими:

$ foo
a/foo

Ни which, ни type не могут заранее знать, что b/foo не может быть выполнен. Некоторые оболочки, такие как bash, ksh или yash, при вызове foo действительно попытаются выполнить b/foo и сообщат об ошибке, в то время как другие (как zsh, ash, csh, Bourne, tcsh) выполнит a/foo при неудаче системного вызова execve() для b/foo.

Одним из моментов, который, похоже, не упомянул Стефан, является то, что which не имеет представления о хэш-таблице путей вашей оболочки. Это приводит к тому, что он может вернуть результат, который не соответствует тому, что на самом деле выполняется, что делает его неэффективным при отладке.

Я часто использую which, чтобы быстро перейти к исполняемому файлу так: vim $(which my_executable). Недавно я нашел этот пост и был довольно удивлен — я делал это неправильно все это время? Но потом я проверил все ответы и не нашел причин полностью отказать от which: (вывод остается без изменений)

$ type -a pacman
pacman is aliased to `pacman'
pacman is /usr/bin/pacman
$ command -v pacman
alias pacman='pacman'
$ which pacman
/usr/bin/pacman
$ bash --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)

Команда which является сломанным наследием от C-Shell и лучше ее оставить в покое в оболочках, подобным Bourne.

Я думаю, что следует использовать любой инструмент, если он удовлетворяет всем вашим требованиям. Я использую which, чтобы находить путь к исполняемому файлу в $PATH, и, конечно, это не подходящий инструмент, чтобы изучить, что на самом деле скрывается за вашей командой, и тогда type и command лучше подойдут.

(Так как этот вопрос помечен как “переносимость”, различные интерпретации вопроса исключены, включая “интерактивное использование” и “меня заботит только система, которую я использую”. Таким образом, этот ответ учитывает только Почему нельзя делать это в сценарии оболочки?)

Стефан представил всесторонний анализ вариантов, с указанием, почему каждый из них хорош или плох. Нет одной причины, почему which — всегда неверный ответ. Скорее, множество мелких факторов, способствующих этому. Хотя вы можете быть терпимы к одному или нескольким из них, в совокупности они могут изменить ваше мнение.

Одна причина, которая еще не была упомянута, чтобы не использовать which, это то, что это поднимает вопрос:

Почему вы хотите результат which с самого начала?

Под этим я имею в виду, что иногда цель не должна заключаться в том, чтобы найти замену для which, а скорее в том, чтобы реорганизовать код таким образом, чтобы не было необходимости в этом изначально.

Распространенный шаблон:

CMD=$( which cmd )

# некоторое время спустя...
$CMD --some --args

Не учитывая тот факт, что $CMD почти всегда не заключен в кавычки, я бы утверждал, что весь этот шаблон сломан.

Одно дело жестко закодировать CMD=/my/path/to/cmd, когда цель заключается в том, чтобы избежать зависимости от $PATH.

Но если вы собираетесь искать в $PATH в любом случае, то это почти всегда не имеет смысла. Уберите which и $CMD полностью, и просто запишите:

cmd --some --args

Если вы думаете, что вам нужен путь, потому что вы хотите внедрить его в функцию или псевдоним, тогда вот где command может помочь:

function cmd {
    command cmd --extra-arg "$@"
}

Конечно, есть исключения, когда вам нужна программа, основанная на другом PATH. В таком случае рассмотрите возможность использования:

function cmd {
    PATH=$OTHERPATH command cmd "$@"
}

Суть, в общем, заключается в том, чтобы избегать ментального укорочения “как мне получить путь к команде”, и вместо этого рассматривать каждый случай индивидуально: действительно ли мне нужен путь и почему?

В некоторых случаях which может быть приемлем, но, по крайней мере, иногда есть лучшие решения. Если вы пишете учебник для других людей, пожалуйста, постарайтесь вдумчиво рассмотреть другие варианты.

Даже если вы думаете, что CMD=$( which cmd ) ; ... $CMD args оправдан, есть еще причины избегать which

Он не универсален

Список команд, требуемых POSIX, включает command и type, но не which.

Формат его вывода не уточнен

which обязан лишь указать путь к указанной команде, а не предоставлять его дословно и без комментариев. Хотя большинство версий делают это.

Вполне законно, если which foo выводит что-то вроде:

• foo might be /opt/foobar/bin/foo (unverified); или
• foo is in /bin; или
• ~foo/bin/foo (где ~foo обозначает домашний каталог foo); или
• /proc/1234/root/bin/foo (где процесс 1234 с тех пор завершил работу)

Ответ может устареть

(это в основном исключает все формы CMD=$( что-то ) ; ... $CMD ... и не является специфическим для which.)

По разным причинам расположение исполняемого файла для данного имени команды может измениться.

Иногда вы хотите старое расположение, а иногда нет.

Иногда путь к команде является относительным (начинается с ., а не /). Это редкость, потому что обычно это рассматривается как риск безопасности, но это все еще может применяться в особых случаях, в таком случае простое выполнение cd может аннулировать путь к программе.

Честно говоря, which это то, что это.
Он работал для меня на протяжении многих лет, ОС и платформ.

Моя рекомендация: используйте это.

Я использую это все время в командной строке.

Действительно, я никогда не буду использовать это в сценарии. Суть в том, что
я не должен это использовать в сценариях.

Я бы не использовал which, чтобы обнаружить конкретную версию чего-либо.

Есть небольшое исключение.
В современное время, не Sys V, разработчики, действительно, помещают системные команды,
“где-то”.
Здесь which, возможно, должен определить базовую команду.