Контрольный список: когда писать переносимый/POSIX-совместимый код оболочки?

Question

Многие разработчики оболочек тратят много усилий на разработку портативного кода, избегая, например, Bashisms, и я задаюсь вопросом, насколько это увеличение усиливает действительно способствует соблюдению требований к программному обеспечению.

Интересно, можно ли дать простой контрольный список условий, требующих портативного кода. Допустим

• , что использование оболочки вместо $BETTER_LANGUAGE на самом деле имеет смысл,
• , что каждая оболочка имеет ту же версию на всех целевых системах (т.е. оболочки версия различия не являются частью переносимости),
• что читаемости/изменчивость не рассматривается на данный момент (переносимый код может быть легче читать/понимать, чем, например, новейшая функция Bash RegEx).

Это то, что пришло на мой взгляд, до сих пор:

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

Есть ли очевидные условия, о которых я не думал, или они могут быть выражены более широко? Соответствует ли соответствие POSIX другому контрольному списку, чем общая переносимость? Есть ли литература или другой источник, который вы бы рекомендовали?

Answer 1

Интересно, насколько это усиленное усилие действительно способствует соблюдению требований к программному обеспечению.

Это - «это усиленное усилие» - предполагает, что выбор оболочки в качестве языка программирования был неправильным в первую очередь. Shell - это язык сантехники: вы НЕ реализуете в нем инструменты - вы управляете другими инструментами. Если сценарий оболочки требует много времени, чтобы развить, если вы сталкиваетесь с ограничениями оболочки POSIX, то оболочка, скорее всего, является неправильным языком.

Единственное исключение из этого списка и что-то, отсутствующее в вашем контрольном списке, - это окружение пустой, как если бы свеже установленной коммерческой системы UNIX (и, вероятно, некоторых из * BSD-систем). Если вы разрабатываете программное обеспечение для таких систем, то вам, вероятно, придется использовать оболочку POSIX, просто потому, что в системе может быть буквально ничего (как буквально «буквально ничего»).

В конце концов, все программное обеспечение поставляется со списком зависимостей и предварительных условий. Если вы включите в качестве зависимости bash, это не мешает никакому администратору NIX: bash часто является первым пакетом сторонних разработчиков, установленным на таких системах. Кроме того, по сравнению с другим сторонним программным обеспечением bash (как и другие популярные оболочки, например csh, tcsh, ksh), в буквальном смысле свободны от проблем с установкой и зависимостью.

Соответствие POSIX требует наличия другого контрольного списка, кроме общей переносимости?

Нет такой вещи, как «общая переносимость». Переносимость всегда частности.

Программная переносимость, в широком смысле, является способностью программного обеспечения работать в двух или более различных операционных системах. POSIX - это стандарт операционной системы, определяющий часть интерфейсов ОС для пользователей и разработчиков программного обеспечения. Это платформа, а не платформа.

Требования к соблюдению требований POSIX Я видел только на некоторых рынках ниши. Часто по одной только причине, что он является единственным стандартом ISO операционной системы.

Для программного обеспечения, которое не имеет жесткого требования к «соблюдению POSIX», обычно рекомендуется ориентировать определенные платформы. Общий знаменатель может по-прежнему быть стандартом POSIX, но специфические функции, настройки и обработка ОС просто делают программное обеспечение лучше для пользователей конкретной платформы.

В конце концов, пользователи не заботятся о POSIX. POSIX - это инструмент для разработчиков. Разработчики используют его для снижения затрат на разработку и обслуживание программного обеспечения для нескольких платформ. Таким образом, требование, поскольку оно исходит от пользователей, - это поддержка определенной платформы, а не «соответствие POSIX».