Re: Q on Bash's self-documented POSIX compliance...

[Mike Frysinger]

On Sunday 27 January 2013 03:22:35 Pierre Gaston wrote:
> On Sun, Jan 27, 2013 at 5:52 AM, John Kearney <dethrophes@web.de> wrote:
> > Am 27.01.2013 01:37, schrieb Clark WANG:
> >> On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh <bash@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.