Когда sh является символьной ссылкой на удар или тире, удар ограничивает себя соответствием POSIX, таким образом, это должно быть на 100% совместимо с sh?

Question

Когда sh является символьной ссылкой на удар или тире, удар ограничивает себя соответствием POSIX, таким образом, это должно быть на 100% совместимо с sh?

Нет, нет абсолютно никакой причины, почему необходимо создать X (или большинство программ) в той же операционной системе, что Вы будете работать на ней. Это часто более трудно, иногда даже невозможно, для создания программного обеспечения для другой архитектуры процессора (amd64/arm/ppc/x86 / …). Создание для другой операционной системы легче, и точная версия ядра абсолютно не важна (если Вы не создаете модули ядра).

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

8

dash shell-script shell bash

Gilles 'SO- stop being evil' 07.08.2012, 02:30

Ссылка

2 ответа

Кажется, существует некоторый беспорядок вокруг Оболочки Bourne. Оболочка Bourne была оболочкой Unix несколько десятилетий назад в дни предPOSIX. В наше время "sh" является реализацией или другой из оболочки, которая реализует спецификацию POSIX, среди которой у нас есть удар, pdksh, AT&T ksh, более новые оболочки Almquist и их производные, которые были сделаны совместимым POSIX (включая "sh" некоторого BSDs, другой BSDs sh бывший основанный pdksh и пепел Debian (тире)). Даже zsh имеет режим, в котором это - главным образом совместимый POSIX.

Оболочка Bourne не является совместимым POSIX, и не может быть найдена на многих систему в наше время. Где Оболочка Bourne найдена или где это не, всегда будет "sh", который является совместимым POSIX (и не будет Оболочка Bourne), обычно в /bin в то время как известным (раздражающим) исключением является Солярис.

Обратите внимание, что перед Оболочкой Bourne, и который мы обсуждаем 30 лет назад, "sh" был оболочкой Thompson. Мы не пишем сценарии, совместимые с оболочкой Thompson больше. Точно так же мы должны прекратить думать о "sh" как об Оболочке Bourne.

Теперь "sh" является спецификацией, не многими когда-то несовместимые варианты реализации. Это делает намного легче записать портативные сценарии. Просто следуйте за спецификацией.

Это идет для "sh" и всех стандартных утилит (sed, сокращение, TR...)

8

Stéphane Chazelas 27.01.2020, 20:08

Ссылка

1

+1 раздела для "записи к спецификации". Но печально это достаточно часто для мобильности. Например, что, если Вы хотите использовать шаблоны egrep-стиля в sed? Спецификация не предусматривает это. В системах с Основанными на гну утилитами (или BusyBox), Вы используете sed -r. В системах с основанными на BSD утилитами Вы используете sed -E. sed FreeBSD принимает обоих, но единственный Mac OS X принимает -E. И так далее и так далее. положительная сторона – dubiousjim 23.09.2012, 23:08
2

Это не относится к делу. Спецификация не обеспечивает его, таким образом, Вы не можете использовать его portably/POSIXly. Если Вы используете BREs, который будет работать над всем POSIX совместимые системы, это - гарантия, данная POSIX, вот почему это полезно. За пределами POSIX, как Вы говорите, нет никакой надежды, поскольку семена или не поддерживают ДО или поддерживают его с другой опцией или отличающийся ДО синтаксис. Обратите внимание, что EREs менее способны, чем BREs (только синтаксис расширяется в EREs для сохранения Вас некоторый ввод. EREs может быть переведен в BREs, обратное не верно (BRE's $...$\1 не имеет никакого перевода в стандартном EREs). – Stéphane Chazelas 24.09.2012, 09:12
3

я понимаю, что (POSIX) EREs испытывают недостаток в обратных ссылках; на самом деле я участвовал в редактировании той части стандарта. Это не корректно, что POSIX, EREs строго менее способны, чем BREs, начиная с в текущем стандарте, чередование, не определяется для BREs. Однако я не знаю ни о каком regex механизме, который не соблюдает \| для BREs. Я - все для записи максимально портативно. Я только делал (я думал широко ценивший), наблюдение, что это может быть болезненно, и иногда пишущий в POSIX просто не возможно. Где-нибудь имейте ссылки, которые показывают много таких извращений; будет искать их. – dubiousjim 24.09.2012, 09:50
4

у чередования, я забыл об этом, и признать ошибку. С sed это вряд ли будет блокироваться хотя, поскольку можно использовать несколько выражений для соответствия альтернативе regexps. Существует awk в стандарте toolchest, который может использоваться, если EREs необходимы. Я очень редко оказываюсь по стандарту toolchest, и когда я делаю, это обычно - случаи, где другой язык как жемчуг является более соответствующим, но я действительно вижу Вашу точку (хотя я все еще думаю, что это не относится к делу в этом потоке о записи портативных сценариев) – Stéphane Chazelas 24.09.2012, 10:18
5

Пример я думал бесцеремонно: строки хижины (наверху каждого сценария оболочки) не указаны в POSIX. Кроме того, я не уверен, что когда-либо использовал систему, которая составляла 100% совместимого POSIX. Например, POSIX говорит, что можно включать новые строки внутри ${VAR:=stuff...here} но много оболочек не позволяют Вам, необходимо поместить кавычки вокруг stuff...here. – dubiousjim 24.09.2012, 10:20

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

+1 раздела для "записи к спецификации". Но печально это достаточно часто для мобильности. Например, что, если Вы хотите использовать шаблоны egrep-стиля в sed? Спецификация не предусматривает это. В системах с Основанными на гну утилитами (или BusyBox), Вы используете sed -r. В системах с основанными на BSD утилитами Вы используете sed -E. sed FreeBSD принимает обоих, но единственный Mac OS X принимает -E. И так далее и так далее. положительная сторона — dubiousjim, 23.09.2012, 23:08
Это не относится к делу. Спецификация не обеспечивает его, таким образом, Вы не можете использовать его portably/POSIXly. Если Вы используете BREs, который будет работать над всем POSIX совместимые системы, это - гарантия, данная POSIX, вот почему это полезно. За пределами POSIX, как Вы говорите, нет никакой надежды, поскольку семена или не поддерживают ДО или поддерживают его с другой опцией или отличающийся ДО синтаксис. Обратите внимание, что EREs менее способны, чем BREs (только синтаксис расширяется в EREs для сохранения Вас некоторый ввод. EREs может быть переведен в BREs, обратное не верно (BRE's $...$\1 не имеет никакого перевода в стандартном EREs). — Stéphane Chazelas, 24.09.2012, 09:12
я понимаю, что (POSIX) EREs испытывают недостаток в обратных ссылках; на самом деле я участвовал в редактировании той части стандарта. Это не корректно, что POSIX, EREs строго менее способны, чем BREs, начиная с в текущем стандарте, чередование, не определяется для BREs. Однако я не знаю ни о каком regex механизме, который не соблюдает \| для BREs. Я - все для записи максимально портативно. Я только делал (я думал широко ценивший), наблюдение, что это может быть болезненно, и иногда пишущий в POSIX просто не возможно. Где-нибудь имейте ссылки, которые показывают много таких извращений; будет искать их. — dubiousjim, 24.09.2012, 09:50
у чередования, я забыл об этом, и признать ошибку. С sed это вряд ли будет блокироваться хотя, поскольку можно использовать несколько выражений для соответствия альтернативе regexps. Существует awk в стандарте toolchest, который может использоваться, если EREs необходимы. Я очень редко оказываюсь по стандарту toolchest, и когда я делаю, это обычно - случаи, где другой язык как жемчуг является более соответствующим, но я действительно вижу Вашу точку (хотя я все еще думаю, что это не относится к делу в этом потоке о записи портативных сценариев) — Stéphane Chazelas, 24.09.2012, 10:18
Пример я думал бесцеремонно: строки хижины (наверху каждого сценария оболочки) не указаны в POSIX. Кроме того, я не уверен, что когда-либо использовал систему, которая составляла 100% совместимого POSIX. Например, POSIX говорит, что можно включать новые строки внутри ${VAR:=stuff...here} но много оболочек не позволяют Вам, необходимо поместить кавычки вокруг stuff...here. — dubiousjim, 24.09.2012, 10:20

Ulrich Dangel · Accepted Answer · 27.01.2020, 20:08

Нет, если /bin/sh символьная ссылка состоит в том, чтобы колотить удар, переходит просто posix к режиму - от удара человека:

При вызове как sh удар переходит к posix режиму после того, как файлы запуска читаются.

Если Вы теперь будете искать posix режим в странице справочника удара, то Вы будете видеть что некоторая оболочка builtins как time или source ведите себя по-другому. Это - все. bashishms как запись function прежде, чем объявить функцию или использовать source вместо . все еще будет работать, но команды могут вести себя по-другому.

Итак, если /bin/sh символьная ссылка на /bin/bash все еще работают все типичные bashishms.

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

16

Ulrich Dangel 27.01.2020, 20:08

Ссылка

1

Таким образом, я предполагаю, что лучшая вещь сделать состоит в том, чтобы протестировать весь сценарий в checkbashism инструменте. Я слышал, что некоторый дистрибутив, как Debian и Ubuntu (подтверждение потребности для этого) имел их bin/sh теперь символьная ссылка на тире. Действительно подчеркивает штриховой линией совместимо с оболочкой ручья? Если да, то по крайней мере весь Debian и сценарий оболочки Ubuntu должны быть прекрасными в соответствии с FreeBSD. – user1115057 06.08.2012, 05:39
2

@user1115057 только сценарии оболочки с /bin/sh как хижина. Сценарий оболочки все еще может явно использовать /bin/bash. Так или иначе большинство сценариев оболочки, вероятно, будет хорошо работать под/bin/sh, но проблемой будут пользовательские инструменты, например, большая часть сценария оболочки ожидает пространство пользователя GNU, которое, вероятно, будет большим количеством проблемы, чем просто некоторая синтаксическая ошибка. Я также добавил ссылку к ссылке удара, которая перечисляет другое поведение в posix режиме – Ulrich Dangel 06.08.2012, 05:43
3

хорошо от того, что я считал, пепел использования BSD как их bin/sh, в то время как тире использования Debian & Ubuntu. Если они окружают, совместимы, это означает меня, привычка больше имеет проблему с хижиной #!/bin/sh. Но поскольку Вы сказали, будет другая проблема, связанная с пространством пользователя... тире – user1115057 06.08.2012, 06:33
4

@user1115057 также не прекрасен, например, wiki.ubuntu.com/DashAsBinSh/#echo так или иначе большинство сценариев оболочки довольно просто и может быть портировано довольно легко … удача – Ulrich Dangel 06.08.2012, 06:45
5

, Но тире, и пепел совместимое право? – user1115057 06.08.2012, 06:54

Когда sh является символьной ссылкой на удар или тире, удар ограничивает себя соответствием POSIX, таким образом, это должно быть на 100% совместимо с sh?

Теги

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