关于Shell移植的话题
我们一般讨论的是关于在GNU/Linux 系统下的Bash 编程但。同样，sh 和 ksh 用户也能在这儿得到许多有用的价值。
以现在的情况来看,许多种shell 和脚本语言都尽力使自己符合 POSIX 1003.2 标准。用--posix 选项调用Bash 或在脚本开头插入 set -o posix 就能使Bash 能以很接近这个标准的方式运行。在脚本开头用
#!/bin/sh
比用
#!/bin/bash
会更好。注意在Linux 和一些UNIX 风格的系统里/bin/sh 是/bin/bash 的一个链接(link)，并且如果脚本以/bin/sh 调用时会禁用Bash 的扩展功能。
大多数的 Bash 脚本能不作修改就能运行在 ksh 下，反之亦然，因为 Chet Ramey 辛勤地把 ksh的属性移植到了最新的Bash 版本。
在商业的 UNIX 机器上，使用了GNU 扩展属性的标准命令的脚本可能不会工作。这个问题在最近几年已经有所改观了，因为GNU 软件包完美地代替了在这些"大块头的"UNIX 运行的相应工具。
源码分发给传统UNIX 上加快了这种趋势。Bash 有传统的 Bourne shell 缺乏的一些属性。下面是其中一些：
以现在的情况来看,许多种shell 和脚本语言都尽力使自己符合 POSIX 1003.2 标准。用--posix 选项调用Bash 或在脚本开头插入 set -o posix 就能使Bash 能以很接近这个标准的方式运行。在脚本开头用
#!/bin/sh
比用
#!/bin/bash
会更好。注意在Linux 和一些UNIX 风格的系统里/bin/sh 是/bin/bash 的一个链接(link)，并且如果脚本以/bin/sh 调用时会禁用Bash 的扩展功能。
大多数的 Bash 脚本能不作修改就能运行在 ksh 下，反之亦然，因为 Chet Ramey 辛勤地把 ksh的属性移植到了最新的Bash 版本。
在商业的 UNIX 机器上，使用了GNU 扩展属性的标准命令的脚本可能不会工作。这个问题在最近几年已经有所改观了，因为GNU 软件包完美地代替了在这些"大块头的"UNIX 运行的相应工具。
源码分发给传统UNIX 上加快了这种趋势。Bash 有传统的 Bourne shell 缺乏的一些属性。下面是其中一些：
- 一些扩展的调用选项(invocation options)
- 使用 $( ) 结构来完成命令替换(Command substitution)
- 一些字符串处理(string manipulation) 操作符
- 进程替换(Process substitution)
- Bash 的内建(builtins) 命令
