On Sun, Jan 27, 2013 at 5:52 AM, John Kearney <dethrop...@web.de> wrote: > Am 27.01.2013 01:37, schrieb Clark WANG: >> On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh <b...@tlinx.org> wrote: >> >>> I noted on the bash man page that it says it will start in posix >>> compliance mode when started as 'sh' (/bin/sh). >>> >>> What does that mean about bash extensions like arrays and >>> use of [[]]? >>> >>> Those are currently not-POSIX (but due to both Bash and Ksh having >>> them, some think that such features are part of POSIX now)... >>> >>> If you operate in POSIX compliance mode, what guarantee is there that >>> you can take a script developed with bash, in POSIX compliance mode, >>> and run it under another POSIX compliant shell? >>> >>> Is it such that Bash can run POSIX compliant scripts, BUT, cannot be >>> (easily) used to develop such, as there is no way to tell it to >>> only use POSIX? >>> >>> If someone runs in POSIX mode, should bash keep arbitrary bash-specific >>> extensions enabled? >>> >>> I am wondering about the rational, but also note that some people believe >>> they are running a POSIX compatible shell when they use /bin/sh, but would >>> get rudely surprised is another less feature-full shell were dropped in >>> as a replacement. >>> >> I think every POSIX compatible shell has its own extensions so there's no >> guarantee that a script which works fine in shell A would still work in >> shell B even if both A and B are POSIX compatible unless the script writer >> only uses POSIX compatible features. Is there a pure POSIX shell without >> adding any extensions? > dash is normally a better gauge of how portable your script is, than > bash in posix mode.
It is, but it still has a couple of extensions over the standard There's also posh around. As for the rationale, making it strictly compatible in order to test scripts probably requires quite some more work and I bet Chet would not be against a --lint option or something like that but it may not be his primary objective.
