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

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

На подобных Границе оболочках мы сравниваем вывод which с выводом type (type будучи встроенной оболочкой, это предназначено, чтобы быть наземной истиной, поскольку это - оболочка, говоря нам, как это вызвало бы команду).

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

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

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

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

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

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

$ 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;
}

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

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

$ 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 встроено),

Солярис 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

Это вызвано тем, что на большинстве коммерческих Нельдов, which (как в исходной реализации на 3BSD), a 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

(Солярис и версии 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

(конечно, будучи a csh сценарий Вы не можете ожидать, что это будет работать с аргументами, содержащими пробелы...),

CentOS 6.4, удар

$ 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 alias но не знает, как проанализировать его правильно и использует эвристику (один псевдоним на строку, ищет первую найденную команду после a |, ;, &...)

Худшая вещь на 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 a /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значение по умолчанию PATH который отличается от ksh93

Это не лучше с GNU which который сообщает:

which: no which in ((null))

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

удар, любая система:

Тот Chris относится к в его ответе:

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

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

Сводка

Для получения пути исполняемого файла в подобном Границе сценарии оболочки (существует несколько протестов; посмотрите ниже):

ls=$(command -v ls)

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

if command -v given-command > /dev/null 2>&1; then
  echo given-command is available
else
  echo given-command is not available
fi

При подсказке интерактивной подобной Границе оболочки:

type ls

which команда является поврежденным наследием от Оболочки C и лучше оставлена в покое в подобных Границе оболочках.

Варианты использования

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

Начальная буква type команда перенесена от подобной проблемы как which сценарий в этом, это не возвратило статус выхода отказа, если команда не была найдена. Кроме того, для исполняемых файлов, вопреки which, это произвело что-то как ls is /bin/ls вместо просто /bin/ls который сделал это менее простым в использовании в сценариях.

Версия 8 Unix (не выпущенный в дикой природе) Оболочка Bourne имела, это type встроенный переименованный к whatis. И Plan9 (некогда будущий преемник Unix) оболочка rc (и его производные как akanga и es) иметь whatis также.

Оболочка Korn (подмножеством которого POSIX sh определение на основе), разработанный в середине 80-х, но не широко доступная до 1988, добавила многие из csh функции (строчный редактор, псевдонимы...) сверху Оболочки Bourne. Это добавило свое собственное whence встроенный (в дополнение к type) который выбрал несколько вариантов (-v обеспечить type- как подробный вывод, и -p только искать исполняемые файлы (не искажает/функционирует...)).

Случайный к суматохе относительно разногласий по авторскому праву между AT&T и Беркли, несколько реализаций оболочки бесплатного программного обеспечения вышли в конце 80-х в начале 90-х. Вся оболочка Almquist (пепел, чтобы быть заменой Оболочки Bourne в BSDs), реализация общественного достояния ksh (pdksh), bash (спонсируемый FSF), zsh вышел промежуточные 1989 и 1991.

Пепел, хотя предназначено быть заменой для Оболочки Bourne не имел a type встроенный значительно позже (в NetBSD 1.3 и FreeBSD 2.3), хотя это имело hash -v. OSF/1 /bin/sh имел a type встроенный, который всегда возвращался 0 до OSF/1 v3.x. bash не добавил a whence но добавил a -p опция к type распечатать путь (type -p был бы похож whence -p) и -a сообщить обо всех командах соответствия. tcsh сделанный which встроенный и добавил a where команда, действующая как bash type -a. zsh имеет их всех.

fish оболочка (2005) имеет a type команда, реализованная как функция.

which сценарий csh между тем был удален из NetBSD (поскольку это было встроено в tcsh и не много использования в других оболочках), и функциональность, добавленная к whereis (при вызове как which, whereis ведет себя как which за исключением того, что это только ищет исполняемые файлы в $PATH). В OpenBSD и FreeBSD, which был также изменен на один записанный в C, который ищет команды в $PATH только.

Реализации

Существуют десятки реализаций a which команда на различных Нельдах с другим синтаксисом и поведением.

На Linux (около встроенных в tcsh и zsh) мы находим несколько реализаций. В недавних системах Debian, например, это - простой сценарий оболочки POSIX, который ищет команды в $PATH.

busybox также имеет a which команда.

Существует a GNU which который является, вероятно, самым экстравагантным. Это пытается расшириться что which сценарий csh сделал к другим оболочкам: можно сказать это, что - псевдонимы и функции то, так, чтобы это могло дать Вам лучший ответ (и я полагаю, что некоторые дистрибутивы Linux устанавливают некоторые глобальные псевдонимы вокруг этого для bash сделать это).

zsh имеет несколько операторов для расширения до пути исполняемых файлов: = оператор расширения имени файла и :c модификатор расширения истории (здесь относился к расширению параметра):

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

zsh, в zsh/parameters модуль также делает хеш-таблицу команды как commands ассоциативный массив:

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

whatis утилита (за исключением той в оболочке Bourne Unix V8 или Плане 9 rc/es) действительно не связан, как это для документации только (захватывает whatis базу данных, которая является резюме страницы справочника).

whereis был также включен 3BSD в то же время, что и which хотя это было записано в C, нет csh и привык к поиску одновременно, исполняемому файлу, странице справочника и источнику, но не на основе текущей среды. Таким образом, снова это отвечает на другую потребность.

Теперь, на стандартной передней стороне, POSIX указывает command -v и -V команды (который раньше был дополнительным до POSIX.2008). UNIX указывает type команда (никакая опция). Это - все (where, which, whence не указаны ни в каком стандарте),

Некоторая версия, type и command -v были дополнительными в Стандарте Linux Основная спецификация, которая объясняет почему, например, некоторые старые версии posh (хотя на основе pdksh то, которое имело обоих), не имело также. command -v был также добавлен к некоторым реализациям Оболочки Bourne (как на Солярисе).

Состояние сегодня

Состояние в наше время - это type и command -v повсеместны во всех подобных Границе оболочках (хотя, как отмечено @jarno, отмечают протест/ошибку в bash если не в режиме POSIX или некоторых потомках Almquist окружают ниже в комментариях). tcsh единственная оболочка, где Вы хотели бы использовать which (как существует нет type там и which встроено).

В оболочках кроме tcsh и zsh, which может сказать Вам путь данного исполняемого файла, пока нет никакого псевдонима или функции тем же самым именем ни в одном из нашего ~/.cshrc, ~/.bashrc или любая оболочка запускает файл, и Вы не определяете $PATH в Вашем ~/.cshrc. Если у Вас есть псевдоним или функция, определяемая для него, он может или не может сказать Вам об этом или сказать Вам неправильную вещь.

Если Вы хотите знать обо всех командах именем, нет ничего портативного. Вы использовали бы where в tcsh или zsh, type -a в bash или zsh, whence -a в ksh93 и в других оболочках, можно использовать type в сочетании с which -a который может работать.

Рекомендации

Получение пути к исполняемому файлу

Теперь, для получения пути исполняемого файла в сценарии существует несколько протестов:

ls=$(command -v ls)

был бы стандартный способ сделать это.

Существует несколько проблем хотя:

• Не возможно знать путь исполняемого файла, не выполняя его. Весь type, which, command -v... вся эвристика использования для обнаружения пути. Они циклично выполняются через $PATH компоненты и находят первый файл некаталога, для которого Вы имеете, выполняют разрешение. Однако в зависимости от оболочки, когда дело доходит до выполнения команды, многие из них (Граница, AT&T ksh, zsh, пепел...) просто выполнят их в порядке $PATH до execve системный вызов не возвращается с ошибкой. Например, если $PATH содержит /foo:/bar и Вы хотите выполниться ls, они сначала попытаются выполниться /foo/ls или если это перестало работать /bar/ls. Теперь выполнение /foo/ls может перестать работать, потому что у Вас нет разрешения выполнения, но также и по многим другим причинам, как он не допустимый исполняемый файл. command -v ls сообщил бы /foo/ls если у Вас есть разрешение выполнения для /foo/ls, но выполнение ls мог бы на самом деле работать /bar/ls если /foo/ls не допустимый исполняемый файл.
• если foo встроенное или функция или псевдоним, command -v foo возвраты foo. С некоторыми оболочками как ash, pdksh или zsh, это может также возвратиться foo если $PATH включает пустую строку и существует исполняемый файл foo файл в текущем каталоге. Существуют некоторые обстоятельства, где Вы, возможно, должны принять это во внимание. Следует иметь в виду, например, что список builtins меняется в зависимости от реализации оболочки (например, mount иногда встроено для busybox sh), и например bash может получить функции от среды.
• если $PATH содержит компоненты относительного пути (обычно . или пустая строка, которую оба отсылают к текущему каталогу, но могли быть чем-либо), в зависимости от оболочки, command -v cmd не мог бы произвести полный путь. Так путь Вы получаете в то время, когда Вы работаете command -v больше не будет допустимо после Вас cd где-то в другом месте.
• Анекдотичный: с оболочкой ksh93, если /opt/ast/bin (хотя тот точный тракт может варьироваться в различных системах, я верю), находится в Вас $PATH, ksh93 сделает доступным несколько дополнительных builtins (chmod, cmp, cat...), но command -v chmod возвратится /opt/ast/bin/chmod даже если тот путь не существует.

Определение, существует ли команда

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

if command -v given-command > /dev/null 2>&1; then
  echo given-command is available
else
  echo given-command is not available
fi

Где можно было бы хотеть использовать which

(t)csh

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

найдите команды только в некоторых оболочках

Случай, где могло бы иметь смысл использовать which то, если Вы хотите знать, что путь команды, игнорируя потенциал окружает builtins или функции в bash, csh (нет tcsh), dash, или Bourne сценарии оболочки, который является оболочками, которые не имеют whence -p (как ksh или zsh), command -ev (как yash), whatis -p (rc, akanga) или встроенное which (как tcsh или zsh) в системах, где which доступно и не csh сценарий.

Если те условия соблюдают, то:

echo=$(which echo)

дал бы Вам путь первого echo в $PATH (кроме угловых случаев), независимо от ли echo также, оказывается, встроенная/искажать/функциональная оболочка или нет.

В других оболочках Вы предпочли бы:

• zsh: echo==echo или echo=$commands[echo] или echo=${${:-echo}:c}
• ksh, zsh: echo=$(whence -p echo)
• yash: echo=$(command -ev echo)
• дистанционное управление, akanga: echo=`whatis -p echo` (остерегайтесь путей с пробелами),
• рыба: set echo (type -fp echo)

Обратите внимание, что, если все Вы хотите сделать, выполняется это echo команда, Вы не должны получать ее путь, можно просто сделать:

env echo this is not echoed by the builtin echo

Например, с tcsh, предотвратить встроенное which от того, чтобы быть используемым:

set Echo = "`env which echo`"

когда Вам действительно нужна внешняя команда

Другой случай, где можно хотеть использовать which когда Вам на самом деле нужна внешняя команда. POSIX требует что вся оболочка builtins (как command) будьте также доступны как внешние команды, но к сожалению это не имеет место для command во многих системах. Например, редко найти a command команда в основанных на Linux операционных системах, в то время как у большинства из них есть a which команда (хотя различные с различными вариантами и поведениями).

Случаи, где можно хотеть внешнюю команду, были бы то, везде, где Вы выполните команду, не вызов оболочку POSIX.

system("some command line"), popen()... функции C или различных языков действительно вызывают оболочку для парсинга той командной строки, таким образом, system("command -v my-cmd") действительно работайте в них. Исключение к этому было бы perl который оптимизирует оболочку, если она не видит специального символа оболочки (кроме пространства). Это также относится к его оператору обратной галочки:

$ 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

Добавление этого :; выше сил perl вызвать оболочку там. При помощи which, Вы не должны были бы использовать тот прием.

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

We often hear that which should be avoided. Why? What should we use instead?

Никогда такого не слышал. Пожалуйста, приведите конкретные примеры. Я бы побеспокоился о вашем дистрибутиве Linux и установленных пакетах программного обеспечения, так как это то, откуда взялся which!

SLES 11,4 x 86 -64

в tcsh версии 6.18.01:

> which which

which: shell built-in command.

в версии bash 3.2 -147:

> which which

/usr/bin/which

> which -v

GNU which v2.19, Copyright (C) 1999 - 2008 Carlo Wood.
GNU which comes with ABSOLUTELY NO WARRANTY;
This program is free software; your freedom to use, change
and distribute this program is protected by the GPL.

whichявляется частью util -linux — стандартного пакета, распространяемого организацией ядра Linux для использования в составе операционной системы Linux. Он также предоставляет эти другие файлы

/bin/dmesg
/bin/findmnt
/bin/logger
/bin/lsblk
/bin/more
/bin/mount
/bin/umount
/sbin/adjtimex
/sbin/agetty
/sbin/blkid
/sbin/blockdev
/sbin/cfdisk
/sbin/chcpu
/sbin/ctrlaltdel
/sbin/elvtune
/sbin/fdisk
/sbin/findfs
/sbin/fsck
/sbin/fsck.cramfs
/sbin/fsck.minix
/sbin/fsfreeze
/sbin/fstrim
/sbin/hwclock
/sbin/losetup
/sbin/mkfs
/sbin/mkfs.bfs
/sbin/mkfs.cramfs
/sbin/mkfs.minix
/sbin/mkswap
/sbin/nologin
/sbin/pivot_root
/sbin/raw
/sbin/sfdisk
/sbin/swaplabel
/sbin/swapoff
/sbin/swapon
/sbin/switch_root
/sbin/wipefs
/usr/bin/cal
/usr/bin/chrp-addnote
/usr/bin/chrt
/usr/bin/col
/usr/bin/colcrt
/usr/bin/colrm
/usr/bin/column
/usr/bin/cytune
/usr/bin/ddate
/usr/bin/fallocate
/usr/bin/flock
/usr/bin/getopt
/usr/bin/hexdump
/usr/bin/i386
/usr/bin/ionice
/usr/bin/ipcmk
/usr/bin/ipcrm
/usr/bin/ipcs
/usr/bin/isosize
/usr/bin/line
/usr/bin/linux32
/usr/bin/linux64
/usr/bin/look
/usr/bin/lscpu
/usr/bin/mcookie
/usr/bin/mesg
/usr/bin/mkzimage_cmdline
/usr/bin/namei
/usr/bin/rename
/usr/bin/renice
/usr/bin/rev
/usr/bin/script
/usr/bin/scriptreplay
/usr/bin/setarch
/usr/bin/setsid
/usr/bin/setterm
/usr/bin/tailf
/usr/bin/taskset
/usr/bin/time
/usr/bin/ul
/usr/bin/uname26
/usr/bin/unshare
/usr/bin/uuidgen
/usr/bin/wall
/usr/bin/whereis
/usr/bin/which
/usr/bin/write
/usr/bin/x86_64
/usr/sbin/addpart
/usr/sbin/delpart
/usr/sbin/fdformat
/usr/sbin/flushb
/usr/sbin/freeramdisk
/usr/sbin/klogconsole
/usr/sbin/ldattach
/usr/sbin/partx
/usr/sbin/rcraw
/usr/sbin/readprofile
/usr/sbin/rtcwake
/usr/sbin/setctsid
/usr/sbin/tunelp

у меня util-linuxверсия 2.19. Примечания к выпуску можно легко найти до версии 2.13 от (28 -августа -2007 ). Не уверен, в чем был смысл или цель этого, на него определенно не было ответа в этом длинном вопросе, за который проголосовали 331 раз.