Почему моя программа под названием «set» не выполняется?

Я создал простую программу на C, например:

int main(int argc, char *argv[]) {

    if (argc != 5) {
       fputs("Not enough arguments!\n", stderr);
       exit(EXIT_FAILURE);
    }

И мой PATH был изменен в etc / bash.bashrc примерно так:

PATH=.:$PATH

Я сохранил эту программу как set.c и собираю ее

gcc -o set set.c

в папке

~/Programming/so

Тем не менее, когда я звоню

set 2 3

Ничего не произошло. Там нет текста, который появляется.

призвание

./set 2 3

дает ожидаемый результат

У меня никогда не было проблем с PATH раньше и

which set

возвращается ./set. Так что, кажется, ПУТЬ правильный. Что происходит?

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

$ which set
./set
$ type set
set is a shell builtin

Оболочка всегда ищет встроенные функции перед поиском $PATH, поэтому настройка $PATHздесь не поможет.

Лучше было бы переименовать ваш исполняемый файл во что-то другое, но если ваше назначение требует имени программы set, вы можете использовать функцию оболочки:

$ function set { ./set; }
$ type set
set is a function
set ()
{
    ./set
}

(Это работает bash, но другие оболочки вроде kshне могут этого позволить. См. Ответ mikeserv для более портативного решения.)

Теперь при наборе текста setбудет запущена функция с именем set ./set. GNU bashищет функции перед поиском встроенных функций и ищет встроенные функции перед поиском $PATH. Раздел «КОМАНДНОЕ ИСПОЛНЕНИЕ» на странице руководства bash дает более подробную информацию об этом.

Смотрите также документацию по builtinи command: help builtinи help command.

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

В качестве дополнительного замечания я бы настоятельно рекомендовал не добавлять .путь в целях безопасности. Представьте, например cd, что /tmpпосле того, как любой другой пользователь добавил исполняемый файл /tmp/cd.

setэто не просто встроенная функция, это специальная встроенная функция POSIX . Существует несколько встроенных команд, которые определены стандартами и которые можно найти в поиске команд раньше всего $PATH: поиск не выполняется, имена функций не ищутся и т. Д. Большинство встроенных команд, которые не являются специальными , фактически требуются стандартом POSIX для находится в вашем $PATH до того, как оболочка запустит любую из своих встроенных процедур. Это относится echoи большинство других (хотя ли стандарт почитаются в этом отношении был предметом спора в открытых списках рассылки в прошлом) , но не из set, trap, break,return, continue, ., :, times, eval, exit, export, readonly, unset, Или exec.

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

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

Так что вы могли бы сделать:

alias set=./set

... который будет работать просто отлично.

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

Кстати, на прошлой неделе я задал вопрос о том, как запускать системные команды вместо встроенных команд с тем же именем, и решение, которое я принял, состояло в том, чтобы выполнить команду через env:

env set 2 3

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

./set 2 3

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

Такие предложения, как использование commandвстроенной функции, не будут работать в Bash: это только предотвращает запуск функций оболочки . Хотя это не задокументировано, я также заметил, что использование commandтакже подавляет ключевые слова оболочки . Однако, это не будет делать то же самое для встроенных командных оболочек, таких как set. Насколько я понимаю, commandмогут работать другие оболочки, такие как zsh.

Кроме того , приемы , такие как \setили "set"или 'set'не работать на Bash встроенных команд - хотя они полезны для запуска исполняемых файлов вместо псевдонимов или оболочки ключевых слов .

Примечание. Этот ответ изначально начинался как комментарий к принятому Эрику ответу, но стал слишком большим, чтобы вписаться в комментарий. Другие ответы, рекомендующие использование, typeа не добавление .к PATH, являются хорошими.