Похоже, что cd является отдельным двоичным файлом. Чем выполнение cd (или любого другого встроенного) отличается от выполнения grep (или любого другого не встроенного)?
2 ответа
Важно отметить, что встроенная версия и внешняя программа могут отличаться. В некоторых случаях вы можете предпочесть использование встроенной функции (т. Е. Если вы знаете, в какой оболочке будет использоваться ваш скрипт, но не знаете, какая именно внешняя версия будет выполняться), или наоборот.
Вы можете вызвать внешнюю программу, используя ее полный путь (это обойдёт встроенную функцию).
При вызове внешней программы операционная система запускает отдельный процесс, в то время как встроенная программа является частью самой программы оболочки и, следовательно, будет иметь намного меньшие издержки. Во многих случаях эти издержки незначительны, но если вы собираетесь выполнять команду много раз, это может оказать существенное влияние на производительность вашего скрипта.
В дополнение к правильному ответу Фреда:
Я понимаю ваше замешательство по поводу встроенных и внешних команд. Команда cd на самом деле хороша для небольшой демонстрации.
Например, в моей системе ситуация выглядит следующим образом:
На странице справки встроенной команды cd :
Теперь вы можете увидеть, как команда builtin может использоваться для принудительного выполнения встроенной команды оболочки. Это может быть очень полезно в особых случаях.
Кроме того, вы можете (это на самом деле очевидно) ожидать большей производительности от встроенных команд [источник] :
В общем случае, встроенные команды Bash, при исполнении внутри сценария, не порождают новый подпроцесс, в то время как вызов внешних команд, как правило, приводит к созданию нового подпроцесса.
Ввод/вывод
выводит (на stdout) выражение или содержимое переменной (см. Пример 4-1).
Команда echo может использоваться для передачи информации по конвейеру другим командам.
Кроме того, команда echo, в комбинации с подстановкой команд может учавствовать в операции присвоения значения переменной.
a=`echo «HELLO» | tr A-Z a-z`
Следует запомнить, что команда echo `command` удалит все символы перевода строки, которые будут выведены командой command.
Это встроенная команда Bash и имеет внешний аналог /bin/echo.
Это встроенная команда Bash. Имеет внешний аналог /bin/printf или /usr/bin/printf. За более подробной информацией обращайтесь к страницам справочного руководства man 1 printf по системным командам.
Старые версии Bash могут не поддерживать команду printf.
Пример 11-1. printf в действии
Пример 11-2. Ввод значений переменных с помощью read
Пример 11-3. Пример использования команды read без указания переменной для ввода
Пример 11-4. Ввод многострочного текста с помощью read
Пример 11-5. Обнаружение нажатия на курсорные клавиши
Команда read может считывать значения для переменных из файла, перенаправленного на stdin. Если файл содержит не одну строку, то переменной будет присвоена только первая строка. Если команде read будет передано несколько переменных, то первая строка файла будет разбита, по пробелам, на несколько подстрок, каждая из которых будет записана в свою переменную. Будьте осторожны!
Пример 11-6. Чтение командой read из файла через перенаправление
Передача информации, выводимой командой echo, по конвейеру команде read, будет вызывать ошибку.
Тем не менее, передача данных по конвейеру от cat, кажется срабатывает.
Файловая система
Уже знакомая нам команда cd, изменяющая текущий каталог, может быть использована в случаях, когда некоторую команду необходимо запустить только находясь в определенном каталоге.
Неожиданным образом выполняется команда cd, если ей передать, в качестве каталога назначения, два слэша.
Само собой разумеется, это должен был бы быть каталог /. Эта проблема наблюдается как в командной строке, так и в сценариях.
Пример 11-7. Смена текущего каталога
Переменные
Команда let производит арифметические операции над переменными. В большинстве случаев, ее можно считать упрощенным вариантом команды expr.
Пример 11-8. Команда let, арифметические операции.
Транслирует список аргументов, из списка, в команды.
Пример 11-9. Демонстрация команды eval
Пример 11-10. Принудительное завершение сеанса
Пример 11-11. Шифрование по алгоритму «rot13»
Rory Winston представил следующий пример, как образец практического использования команды eval.
Пример 11-12. Замена имени переменной на ее значение, в исходном тексте программы на языке Perl, с помощью eval
Пример 11-13. Установка значений аргументов с помощью команды set
Вызов set без параметров просто выводит список инициализированных переменных окружения.
Пример 11-14. Изменение значений позиционных параметров (аргументов)
Пример 11-15. «Сброс» переменной
Команда export экспортирует переменную, делая ее доступной дочерним процессам. К сожалению, невозможно экспортировать переменную родительскому процессу. В качестве примера использования команды export можно привести сценарии инициализации системы, вызываемые в процессе загрузки, которые инициализируют и экспортируют переменные окружения, делая их доступными для пользовательских процессов.
Пример 11-16. Передача переменных во вложенный сценарий awk, с помощью export
Допускается объединение инициализации и экспорта переменной в одну инструкцию: export var1=xxx.
Однако, как заметил Greg Keraunen, в некоторых ситуациях такая комбинация может давать иной результат, нежели раздельная инициализация и экспорт.
Команды declare и typeset задают и/или накладывают ограничения на переменные.
Типичная конструкция цикла while с getopts несколько отличается от стандартной из-за отсутствия квадратных скобок, проверяющих условие продолжения цикла.
Пример getopts, заменившей устаревшую, и не такую мощную, внешнюю команду getopt.
Пример 11-17. Прием опций/аргументов, передаваемых сценарию, с помощью getopts
Управление сценарием
Пример 11-18. «Подключение» внешнего файла
Файл data-file для Пример 11-18, представленного выше, должен находиться в том же каталоге.
Сценарий может подключить даже самого себя, только этому едва ли можно найти какое либо практическое применение.
Пример 11-19. Пример (бесполезный) сценария, который подключает себя самого.
Безусловное завершение работы сценария. Команде exit можно передать целое число, которое будет возвращено вызывающему процессу как код завершения. Вообще, считается хорошей практикой завершать работу сценария, за исключением простейших случаев, командой exit 0, чтобы проинформировать родительский процесс об успешном завершении.
Если сценарий завершается командой exit без аргументов, то в качестве кода завершения сценария принимается код завершения последней выполненной команды, не считая самой команды exit.
Это встроенная команда интерпретатора shell, заменяет текущий процесс новым процессом, запускаемым командой exec. Обычно, когда командный интерпретатор встречает эту команду, то он порождает дочерний процесс, чтобы исполнить команду. При использовании встроенной команды exec, оболочка не порождает еще один процесс, а заменяет текущий процесс другим. Для сценария это означает его завершение сразу после исполнения команды exec. По этой причине, если вам встретится exec в сценарии, то, скорее всего это будет последняя команда в сценарии.
Пример 11-20. Команда exec
Пример 11-21. Сценарий, который запускает себя самого
Команда exec так же может использоваться для перенаправления. Так, команда exec stdin) файлом zzz-file (см. Пример 16-1).
Эта команда позволяет изменять ключи (опции) оболочки на лету (см. Пример 23-1 и Пример 23-2). Ее часто можно встретить в стартовых файлах, но может использоваться и в обычных сценариях. Требует Bash версии 2 или выше.
Команды
Возвращает код завершения, свидетельствующий о неудаче, и ничего более.
11.1. Команды управления заданиями
Выводит список заданий, исполняющихся в фоне. Команда ps более информативна.
Задания и процессы легко спутать. Некоторые внутренние команды, такие как kill, disown и wait принимают в качестве параметра либо номер задания, либо номер процесса. Команды fg, bg и jobs принимают только номер задания.
Удаляет задание из таблицы активных заданий командной оболочки.
Команда fg переводит задание из фона на передний план. Команда bg перезапускает приостановленное задание в фоновом режиме. Если эти команды были вызваны без указания номера задания, то они воздействуют на текущее исполняющееся задание.
Останавливает работу сценария до тех пор пока не будут завершены все фоновые задания или пока не будет завершено задание/процесс с указанным номером задания/PID процесса. Возвращает код завершения указанного задания/процесса.
Вы можете использовать команду wait для предотвращения преждевременного завершения сценария до того, как завершит работу фоновое задание.
Пример 11-22. Ожидание завершения процесса перед тем как продолжить работу
При запуске команды в фоне из сценария может возникнуть ситуация, когда сценарий приостанавливает свою работу до тех пор, пока не будет нажата клавиша ENTER. Это, кажется, происходит с командами, делающими вывод на stdout. Такое поведение может вызывать раздражение у пользователя.
Разместив команду wait, после запуска фонового задания, можно предотвратить такое поведение сценария.
Перенаправление вывода в файл или даже на устройство /dev/null также снимает эту проблему.
Действует аналогично нажатию на комбинацию клавиш Control+— Z, за исключением того, что она приостанавливает работу командной оболочки.
Завершает сеанс работы командной оболочки, можно указать необязательный код завершения.
Выдает статистику исполнения команд в единицах системного времени, в следующем виде:
Имеет весьма ограниченную сферу применения, так как сценарии крайне редко подвергаются профилированию.
Принудительное завершение процесса путем передачи ему соответствующего сигнала (см. Пример 13-4).
Пример 11-23. Сценарий, завершающий себя сам с помощью команды kill
Таблица 11-1. Идентификация заданий
Нотация
Описание
%N
Номер задания [N]
%S
Вызов (командная строка) задания, которая начинается со строки S
%?S
Вызов (командная строка) задания, которая содержит строку S
%%
«текущее» задание (последнее задание приостановленное на переднем плане или запущенное в фоне)
%+
«текущее» задание (последнее задание приостановленное на переднем плане или запущенное в фоне)
%-
Последнее задание
$!
Последний фоновый процесс
Примечания
Как правило, исходные тексты подобных библиотек, на языке C, располагаются в каталоге /usr/share/doc/bash-. /functions.
(вывод в переменную), что внешнее /usr/bin/printf просто не сможет сделать, так как у него нет доступа к переменным оболочки в текущем сеансе оболочки (и они не могут их изменить).
Встроенные утилиты также не имеют ограничения, что их расширенная командная строка должна быть короче определенной длины. дела
Поэтому безопасно, если printf это встроенная команда оболочки. Ограничение длины командной строки исходит из execve() функции библиотеки C, используемой для выполнения внешней команды. Если командная строка и текущая среда больше ARG_MAX байтов (см. getconf ARG_MAX В оболочке), вызов execve() завершится ошибкой. Если утилита встроена в оболочку, execve() вызывать не нужно.
Существует небольшой список утилит, которые необходимо встроить в оболочку (взят из списка специальных встроенных модулей стандарта POSIX )
Они должны быть встроены, так как они напрямую управляют средой и потоком программы текущего сеанса оболочки. Внешняя утилита не сможет этого сделать.
Интересно, cd что не входит в этот список, но POSIX говорит об этом следующее :
Поскольку cd влияет на текущую среду выполнения оболочки, она всегда предоставляется как обычная встроенная оболочка. Если он вызывается в подоболочке или в отдельной среде выполнения утилит, например, одной из следующих:
это не влияет на рабочий каталог среды вызывающего.
Поэтому я предполагаю, что «специальные» встроенные модули не могут иметь внешних аналогов, в то время как cd теоретически могут иметь (но это не очень поможет).
В чем разница между ключевым словом shell builtin и shell?
Когда я запускаю эти две команды, я получаю
3 ответа
Существует сильное различие между встроенным и ключевым словом в том, как Bash анализирует ваш код. Прежде чем говорить о различии, давайте перечислим все ключевые слова и встроенные функции:
Ключевое слово отсканировано и понято Bash в самом начале его разбора. Это позволяет, например, следующее:
Это отлично работает, и Bash с радостью выведет
показывает, что Bash не доволен:
На практике вы видите, что это различие допускает сложное поведение, что было бы невозможно со встроенными (или командами).
На практике, как вы можете отличить встроенное от ключевого слова? это забавный эксперимент для выполнения:
О. Это потому, что, когда Bash видит эту строку, он не видит ничего особенного и, следовательно, расширяет все переменные и, в конце концов, видит:
В одних и тех же строках:
Обоснование одно и то же: расширение псевдонима происходит задолго до переменнойрасширение и удаление цитат.
Ключевое слово v.s. Алиас
Теперь, что вы думаете, если мы определяем псевдоним как ключевое слово?
О, это работает! поэтому псевдонимы могут использоваться для ключевых слов с псевдонимами! приятно знать.
С другой стороны, ключевые слова сканируются и понимаются очень рано и допускают сложное поведение оболочки: оболочка сможет запретить расщепление слов или расширение пути и т. д.
Теперь просмотрите список встроенных и ключевых слов и попытайтесь выяснить, почему некоторые из них должны быть ключевыми словами.
, но это запретит такие конструкции, как:
То же самое для time : это более мощно, чтобы иметь ключевое слово, чтобы он мог со временем сложным составным командам и конвейерами перераспределять:
Попробуйте исправить (?) это:
Ключевое слово vs alias?
Как вы думаете, что происходит?
Это распознавание происходит только тогда, когда ни один из символов не цитируется, и когда слово используется как:
Первое слово команды
Первое слово, следующее за одним из зарезервированных слов, отличное от case, for или in
Третье слово в команде case (только в этом случае действительно)
Третье слово в команде for (только в этом случае и действительны в этом случае)
