Почему есть / bin / echo и почему я хочу его использовать?

Да, у каждого дистрибутива Linux, включая Ubuntu, есть каталог

/tmp

Каждый пользователь имеет право на запись в этом каталоге, следовательно, он может создавать файлы внутри него. Эти файлы не сохраняются навсегда - содержимое каталога /tmp удаляется после перезагрузки каждой системы.

47
задан 30 September 2017 в 18:46

6 ответов

Если вы откроете приглашение bash и введите команду echo, которая использует встроенную оболочку вместо запуска /bin/echo. Причинами, по-прежнему важными для существования /bin/echo, являются:

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

Чтобы перейти на # 1, предположим, что вы хотите переместить все обычные файлы, имена которых начинались с abc в любом месте в src до dest. Есть несколько способов сделать это, но один из них:

find src -name 'abc*' -type f -exec mv -nv {} dest/ \;

Но предположим, вместо того, чтобы просто запускать это, вы хотите увидеть каждую команду, которая будет запущена в первую очередь. Ну, тогда вы можете добавить команду echo к команде, как вы могли бы в других контекстах:

find src -name 'abc*' -type f -exec echo mv -nv {} dest/ \;

Но find не использует оболочку. Это /bin/echo.

Кроме bash с -exec или -execdir, исполняемый файл /bin/echo будет вызываться другими программами, которые сами запускают программы, но не через оболочку. Эта оболочка встроена в с командой xargs (которая связана с find), а также в ряде других контекстов, таких как Exec= строка файла .desktop. Другим примером является запуск sudo echo, который может быть полезен для тестирования работы sudo.

Аналогично, некоторые оболочки имеют встроенный printf, но /usr/bin/printf также существует. [!d17 ]

Менее распространенная причина, по которой вы могли бы специально использовать /bin/echo, - это полагаться на различия между ней и командой echo, предоставленной вашей оболочкой. -exec или -execdir документов /bin/echo; help echo в bash документирует встроенный bash. echo не очень портативен, потому что различные реализации - как между операционными системами, так и между оболочками в одной и той же операционной системе - xargs (например, -e) и отличаются в их обработке обратные косые. Разумеется, лучше не полагаться на такие детали, и использовать вместо этого , что гораздо более переносимо.

В bash вы можете сделать type Кроме того, встроенное шоу /bin/echo - если /bin находится в вашем help echo в bash , как это всегда должно быть - передав ему флаг -a:

$ type -a echo
echo is a shell builtin
echo is /bin/echo
84
ответ дан 22 May 2018 в 17:58
  • 1
    А также потому, что спецификация POSIX говорит, что она должна быть такой. – glenn jackman 30 September 2017 в 21:23
  • 2
    @glennjackman Я надеялся, что кто-то опубликует ответ об этом, на самом деле, и я надеюсь, что вы решите сделать это! Однако есть некоторые тонкости, поскольку ни Debian, Ubuntu, ни GNU Coreutils (ни GNU Project в целом) не пытаются выполнить POSIX в все . Например, POSIX настаивает на существовании cd существующего (который при запуске меняет каталог и завершает работу, оставляя вызывающего абонента там, где они были раньше), и некоторые операционные системы имеют один. Может быть полезно указать 4.1 в стандартах GNU . – Eliah Kagan 30 September 2017 в 21:34
  • 3
    @EliahKagan: Incidentaly / usr / bin / cd использует команду: / usr / bin / cd, которая запускает эту команду в этом каталоге. Если сбой каталога не выполняется, команда не запускается. – Joshua 1 October 2017 в 16:31
  • 4
    @Joshua лучше использовать cd просто как тест способности доступа к данному каталогу: если /usr/bin/cd some/dir преуспевает, в одном выстреле вы протестировали: a) что some/dir существует, b) что это каталог или ссылку на одну и в) требуемые разрешения для доступа к этому каталогу; все без изменения собственного состояния. – muru 2 October 2017 в 01:57
  • 5
    @CarlWitthoft, см. Почему printf лучше, чем эхо? Также это /bin/echo, а не \bin\echo, если вы не используете Windows. ;) – Wildcard 3 October 2017 в 06:25

Если вы откроете приглашение bash и введите команду echo, которая использует встроенную оболочку вместо запуска /bin/echo. Причинами, по-прежнему важными для существования /bin/echo, являются:

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

Чтобы перейти на # 1, предположим, что вы хотите переместить все обычные файлы, имена которых начинались с abc в любом месте в src до dest. Есть несколько способов сделать это, но один из них:

find src -name 'abc*' -type f -exec mv -nv {} dest/ \;

Но предположим, вместо того, чтобы просто запускать это, вы хотите увидеть каждую команду, которая будет запущена в первую очередь. Ну, тогда вы можете добавить команду echo к команде, как вы могли бы в других контекстах:

find src -name 'abc*' -type f -exec echo mv -nv {} dest/ \;

Но find не использует оболочку. Это /bin/echo.

Кроме bash с -exec или -execdir, исполняемый файл /bin/echo будет вызываться другими программами, которые сами запускают программы, но не через оболочку. Эта оболочка встроена в с командой xargs (которая связана с find), а также в ряде других контекстов, таких как Exec= строка файла .desktop. Другим примером является запуск sudo echo, который может быть полезен для тестирования работы sudo.

Аналогично, некоторые оболочки имеют встроенный printf, но /usr/bin/printf также существует.

Менее распространенная причина, по которой вы могли бы специально использовать /bin/echo, - это полагаться на различия между ней и командой echo, предоставленной вашей оболочкой. -exec или -execdir документов /bin/echo; help echo в bash документирует встроенный bash. echo не очень портативен, потому что различные реализации - как между операционными системами, так и между оболочками в одной и той же операционной системе - xargs (например, -e) и отличаются в их обработке обратные косые. Разумеется, лучше не полагаться на такие детали, и использовать вместо этого , что гораздо более переносимо.

В bash вы можете сделать type Кроме того, встроенное шоу /bin/echo - если /bin находится в вашем help echo в bash , как и всегда, - передав ему флаг -a:

$ type -a echo echo is a shell builtin echo is /bin/echo
85
ответ дан 18 July 2018 в 05:58

Если вы откроете приглашение bash и введите команду echo, которая использует встроенную оболочку вместо запуска /bin/echo. Причинами, по-прежнему важными для существования /bin/echo, являются:

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

Чтобы перейти на # 1, предположим, что вы хотите переместить все обычные файлы, имена которых начинались с abc в любом месте в src до dest. Есть несколько способов сделать это, но один из них:

find src -name 'abc*' -type f -exec mv -nv {} dest/ \;

Но предположим, вместо того, чтобы просто запускать это, вы хотите увидеть каждую команду, которая будет запущена в первую очередь. Ну, тогда вы можете добавить команду echo к команде, как вы могли бы в других контекстах:

find src -name 'abc*' -type f -exec echo mv -nv {} dest/ \;

Но find не использует оболочку. Это /bin/echo.

Кроме bash с -exec или -execdir, исполняемый файл /bin/echo будет вызываться другими программами, которые сами запускают программы, но не через оболочку. Эта оболочка встроена в с командой xargs (которая связана с find), а также в ряде других контекстов, таких как Exec= строка файла .desktop. Другим примером является запуск sudo echo, который может быть полезен для тестирования работы sudo.

Аналогично, некоторые оболочки имеют встроенный printf, но /usr/bin/printf также существует.

Менее распространенная причина, по которой вы могли бы специально использовать /bin/echo, - это полагаться на различия между ней и командой echo, предоставленной вашей оболочкой. -exec или -execdir документов /bin/echo; help echo в bash документирует встроенный bash. echo не очень портативен, потому что различные реализации - как между операционными системами, так и между оболочками в одной и той же операционной системе - xargs (например, -e) и отличаются в их обработке обратные косые. Разумеется, лучше не полагаться на такие детали, и использовать вместо этого , что гораздо более переносимо.

В bash вы можете сделать type Кроме того, встроенное шоу /bin/echo - если /bin находится в вашем help echo в bash , как и всегда, - передав ему флаг -a:

$ type -a echo echo is a shell builtin echo is /bin/echo
85
ответ дан 24 July 2018 в 18:29

Eliah сделал большую работу, чтобы ответить на это, но я хочу прокомментировать «почему существует другая версия echo, отдельно от части программы Bash». Это неправильный вопрос.

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

Для простота, взгляните на встроенных в тире, ничтожных 38 (bash имеет 61 для сравнения, идя на выходе compgen -b):

.               continue        getopts         readonly        type
:               echo            hash            return          ulimit
[               eval            jobs            set             umask
alias           exec            kill            shift           unalias
bg              exit            local           test            unset
break           export          printf          times           wait
cd              false           pwd             trap
command         fg              read            true

Сколько из них должно быть встроенным ? [, echo, false, printf, pwd, test и true не должны быть встроенными: они не делают ничего, что может сделать только встроенный (влияет или получить состояние оболочки, недоступное внешним командам). Bash printf по крайней мере использует преимущество встроенного: printf -v var сохраняет вывод переменной var. time в bash также является особенным: если вы являетесь ключевым словом, вы можете использовать произвольные списки команд в bash (тире нет эквивалента time). pwd не обязательно должен быть встроенным: любая внешняя команда наследует текущий рабочий каталог (и это , почему это встроено в первую очередь ). : - исключение - вам нужен NOP, а : - это. Остальные делают действия, которые может легко выполнить внешняя команда.

Итак, пятая часть этих встроенных функций не должна быть встроена. Почему тогда? Командная строка dash на самом деле объясняет, почему это встроенные функции (выделение мое):

Builtins This section lists the builtin commands which are builtin because they need to perform some operation that can't be performed by a separate process. In addition to these, there are several other commands that may be builtin for efficiency (e.g. printf(1), echo(1), test(1), etc).

Это в значительной степени это: эти встроенные функции существуют потому, что они используются так часто, в интерактивном режиме и в сценариях , и их функциональность достаточно проста, что оболочка может выполнить эту работу. И так происходит: некоторые (большинство?) Оболочек взяли на себя эту работу. ** Вернитесь к [man] dash manpage из 2.9 BSD, и вы не найдете встроенный echo. [ ! d10]

Итак, вполне возможно, что минимальная оболочка может пропустить реализацию таких команд, как встроенные (но я не думаю, что какая-либо текущая оболочка). Проект GNU coreutils не предполагает, что вы собираетесь запускать их в определенной оболочке, а POSIX требует этих команд. Таким образом, coreutils предоставляет все это и пропускает те, которые не имеют никакого значения вне оболочки.

* Это почти идентично 2.9 BSD [!d12 ], это то, что черта, оболочка Almquist Debian основана на.

** zsh доводит эту идею до крайности: команды, которые вы получаете при загрузке различных модулей, например zmv, вещи, которые вы не думаете, что оболочка нуждается даже в этом. В этот момент возникает реальный вопрос: зачем вы используете bash вместо zsh, который имеет все эти встроенные функции?

30
ответ дан 22 May 2018 в 17:58
  • 1
    Получается, что: не обязательно быть встроенным. Просто глупо, чтобы он не был встроенным. Если вы не сталкиваетесь с проблемами на начальном этапе инициализации на уровне флоппи-диска (в этом случае я обнаружил, что жесткий путь pwd не работает надежно), единственным штрафом за то, что он не является встроенным, является ужасная производительность. – Joshua 1 October 2017 в 16:37
  • 2
    @Joshua no, : как внешний не будет действительно NOP, вы все равно будете искать PATH, попытку выполнить команду и т. Д., Когда все, что вам действительно нужно, - это явно ничего не делать. : как встроенный делает это. – muru 1 October 2017 в 16:39
  • 3
    Bash действительно нуждается в pwd, чтобы быть встроенным, чтобы он работал так, как он делает, с поведением по умолчанию, показывающим «логический». path (pwd -L). /bin/pwd может реализовать только поведение pwd -P, показывая вам фактические родительские каталоги, а не символическую ссылку, которую вы cd просмотрели. – Peter Cordes 1 October 2017 в 23:58
  • 4
    Состояние @PeterCordes pwd немного скомпрометировано наличием PWD, но да, это также экземпляр bash с использованием встроенного состояния для улучшения функциональности – muru 2 October 2017 в 00:10

Eliah сделал большую работу, чтобы ответить на это, но я хочу прокомментировать «почему существует другая версия echo, отдельно от части программы Bash». Это неправильный вопрос.

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

Для простота, взгляните на встроенных в тире, ничтожных 38 (bash имеет 61 для сравнения, идя на выходе compgen -b):

. continue getopts readonly type : echo hash return ulimit [ eval jobs set umask alias exec kill shift unalias bg exit local test unset break export printf times wait cd false pwd trap command fg read true

Сколько из них должно быть встроенным ? [, echo, false, printf, pwd, test и true не должны быть встроенными: они не делают ничего, что может сделать только встроенный (влияет или получить состояние оболочки, недоступное внешним командам). Bash printf по крайней мере использует преимущество встроенного: printf -v var сохраняет вывод переменной var. time в bash также является особенным: если вы являетесь ключевым словом, вы можете использовать произвольные списки команд в bash (тире нет эквивалента time). pwd не обязательно должен быть встроенным: любая внешняя команда наследует текущий рабочий каталог (и это , почему это встроено в первую очередь ). : - исключение - вам нужен NOP, а : - это. Остальные делают действия, которые может легко выполнить внешняя команда.

Итак, пятая часть этих встроенных функций не должна быть встроена. Почему тогда? Командная строка dash на самом деле объясняет, почему это встроенные функции (выделение мое):

Builtins This section lists the builtin commands which are builtin because they need to perform some operation that can't be performed by a separate process. In addition to these, there are several other commands that may be builtin for efficiency (e.g. printf(1), echo(1), test(1), etc).

Это в значительной степени это: эти встроенные функции существуют потому, что они используются так часто, в интерактивном режиме и в сценариях , и их функциональность достаточно проста, что оболочка может выполнить эту работу. И так происходит: некоторые (большинство?) Оболочек взяли на себя эту работу. ** Вернитесь к [man] dash manpage из 2.9 BSD, и вы не найдете встроенный echo. [ ! d10]

Итак, вполне возможно, что минимальная оболочка может пропустить реализацию таких команд, как встроенные (но я не думаю, что какая-либо текущая оболочка). Проект GNU coreutils не предполагает, что вы собираетесь запускать их в определенной оболочке, а POSIX требует этих команд. Таким образом, coreutils предоставляет все это и пропускает те, которые не имеют никакого значения вне оболочки.

* Это почти идентично 2.9 BSD , это то, что черта, оболочка Almquist Debian основана на.

** zsh доводит эту идею до крайности: команды, которые вы получаете при загрузке различных модулей, например zmv, вещи, которые вы не думаете, что оболочка нуждается даже в этом. В этот момент возникает реальный вопрос: зачем вы используете bash вместо zsh, который имеет все эти встроенные функции?

30
ответ дан 18 July 2018 в 05:58

Eliah сделал большую работу, чтобы ответить на это, но я хочу прокомментировать «почему существует другая версия echo, отдельно от части программы Bash». Это неправильный вопрос.

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

Для простота, взгляните на встроенных в тире, ничтожных 38 (bash имеет 61 для сравнения, идя на выходе compgen -b):

. continue getopts readonly type : echo hash return ulimit [ eval jobs set umask alias exec kill shift unalias bg exit local test unset break export printf times wait cd false pwd trap command fg read true

Сколько из них должно быть встроенным ? [, echo, false, printf, pwd, test и true не должны быть встроенными: они не делают ничего, что может сделать только встроенный (влияет или получить состояние оболочки, недоступное внешним командам). Bash printf по крайней мере использует преимущество встроенного: printf -v var сохраняет вывод переменной var. time в bash также является особенным: если вы являетесь ключевым словом, вы можете использовать произвольные списки команд в bash (тире нет эквивалента time). pwd не обязательно должен быть встроенным: любая внешняя команда наследует текущий рабочий каталог (и это , почему это встроено в первую очередь ). : - исключение - вам нужен NOP, а : - это. Остальные делают действия, которые может легко выполнить внешняя команда.

Итак, пятая часть этих встроенных функций не должна быть встроена. Почему тогда? Командная строка dash на самом деле объясняет, почему это встроенные функции (выделение мое):

Builtins This section lists the builtin commands which are builtin because they need to perform some operation that can't be performed by a separate process. In addition to these, there are several other commands that may be builtin for efficiency (e.g. printf(1), echo(1), test(1), etc).

Это в значительной степени это: эти встроенные функции существуют потому, что они используются так часто, в интерактивном режиме и в сценариях , и их функциональность достаточно проста, что оболочка может выполнить эту работу. И так происходит: некоторые (большинство?) Оболочек взяли на себя эту работу. ** Вернитесь к [man] dash manpage из 2.9 BSD, и вы не найдете встроенный echo. [ ! d10]

Итак, вполне возможно, что минимальная оболочка может пропустить реализацию таких команд, как встроенные (но я не думаю, что какая-либо текущая оболочка). Проект GNU coreutils не предполагает, что вы собираетесь запускать их в определенной оболочке, а POSIX требует этих команд. Таким образом, coreutils предоставляет все это и пропускает те, которые не имеют никакого значения вне оболочки.

* Это почти идентично 2.9 BSD , это то, что черта, оболочка Almquist Debian основана на.

** zsh доводит эту идею до крайности: команды, которые вы получаете при загрузке различных модулей, например zmv, вещи, которые вы не думаете, что оболочка нуждается даже в этом. В этот момент возникает реальный вопрос: зачем вы используете bash вместо zsh, который имеет все эти встроенные функции?

30
ответ дан 24 July 2018 в 18:29
  • 1
    Получается, что: не обязательно быть встроенным. Просто глупо, чтобы он не был встроенным. Если вы не сталкиваетесь с проблемами на начальном этапе инициализации на уровне флоппи-диска (в этом случае я обнаружил, что жесткий путь pwd не работает надежно), единственным штрафом за то, что он не является встроенным, является ужасная производительность. – Joshua 1 October 2017 в 16:37
  • 2
    @Joshua no, : как внешний не будет действительно NOP, вы все равно будете искать PATH, попытку выполнить команду и т. Д., Когда все, что вам действительно нужно, - это явно ничего не делать. : как встроенный делает это. – muru 1 October 2017 в 16:39
  • 3
    Bash действительно нуждается в pwd, чтобы быть встроенным, чтобы он работал так, как он делает, с поведением по умолчанию, показывающим «логический». path (pwd -L). /bin/pwd может реализовать только поведение pwd -P, показывая вам фактические родительские каталоги, а не символическую ссылку, которую вы cd просмотрели. – Peter Cordes 1 October 2017 в 23:58
  • 4
    Состояние @PeterCordes pwd немного скомпрометировано наличием PWD, но да, это также экземпляр bash с использованием встроенного состояния для улучшения функциональности – muru 2 October 2017 в 00:10

Другие вопросы по тегам:

Похожие вопросы: