可移植外壳编程资源

便携式外壳编程有哪些资源？最终的答案是在所有目标平台上进行测试，但这几乎不可行。

该POSIX /统一UNIX规范是一个开始，但它会告诉你也不支持每个实现的水平是什么，也没有什么共同的扩展存在。您可以阅读每个实现的文档，但这非常耗时，而且不完全准确。

在我看来，一种理想的格式应该是某种POSIX规范的社区注释版本，其中每个功能都由其在不同实现中的支持级别进行注释。有这样的事吗？还是还有其他有用的资源？

_{例如，有Sven Mascheck的shell可移植性页面，但这仅涉及语法元素和一些内置插件，并且仅涵盖旧的shell。我正在寻找更全面的资源。}

autoconf手册中有一节介绍了 可移植的shell编程。

尽管这并不是专门针对POSIX的，但是它可能是尝试编写可移植的Shell代码时最完整和最不重要的内容。

除了dash和之外posh，还有bournesh（或bsh）传家宝伯恩壳牌，可用于检测Bashisms。

Heirloom项目还包括“ Heirloom Toolchest”，它是100多个标准Unix实用程序的集合（可以用作比较命令行选项的起点）。

与此答案类似，请尝试在posh中执行脚本。

另外，不要忘记将POSIXLY_CORRECT环境变量设置为true，因为这会使许多程序（不仅是shell）更加严格地遵守POSIX标准。

使用破折号编写脚本可能是一个开始。

在某种程度上，您可以尝试checkbashisms使用Debian / Ubuntu的devscripts软件包。

它不是完美的，但是它具有成为现有起点的好处。例如，对于GNU与BSD /其他差异，它看不到带有sed/ 的经典故障find。

默认情况下，它是面向Debian + dash的，该-p标志对于您的情况很有用。

如今，您通常可以在系统上找到POSIX shell，因此通常意味着您可以使用POSIX语言编写脚本（对符合性错误进行模运算）。

唯一的问题是/bin/sh有时不是POSIX shell。而且，您必须将该#!行硬编码为脚本，以使其表现为出色的可执行文件。您不能只要求用户研究问题，然后以调用您的脚本/path/to/posix/shell myscript。

因此，诀窍是在脚本中使用POSIX功能，但要使脚本自动找到POSIX shell。一种方法是这样的：

#!/bin/sh

# At this point, we may be running under some old shell
# we have to tread carefully.

# note how we use test rather than [ ] syntax and avoid
# depending on test with no argument producing a failure;
# i.e. "test $posix_shell".

if ! test x$posix_shell = x ; then
  # the three possible shell paths are just an example;
  # please extend as necessary.

  for shell in /usr/xpg4/bin/sh /bin/bash /usr/bin/bash ; do
    if test -x $shell ; then
       posix_shell=$shell
    fi
  done
  if test x$posix_shell = x ; then
    echo "no POSIX shell found"
    exit 1
    # or we could avoid bailing here and just fall back on /bin/sh:
    # echo "falling back on /bin/sh: cross your fingers that it works"
    # posix_shell=/bin/sh
  fi
  export posix_shell

  # plain "$@" is broken in ancient shells! 
  # I seem to recall ${@+"$@"}: not sure if that's the right trick.

  exec $posix_shell $0 ${@+"$@"}  # can we count on exec in legacy shells? 
fi

# phew, at this point in the script we have been re-executed and are
# being interpreted by some reasonably modern shell. We can use $(...)
# command substitution, and other features.

还有其他方法，例如代码生成。用一个小的脚本来增强脚本，该脚本需要一个不含＃的脚本文件！行，并添加一个。

您可能做的最坏的事情就是开始编写整个脚本，使其在1981年的Bourne shell上运行。只有在您必须为实际上没有任何其他shell的系统编写脚本时，才有必要。