On Sunday 27 January 2013 03:22:35 Pierre Gaston wrote: > 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
right. and there's optional parts of the standard that some shells implement and others omit. > 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. some tool to analyze would be nice -mike
signature.asc
Description: This is a digitally signed message part.
