/bin/sh shell - the posix shell and {} braces expansion case

[Jakub Bogusz]

On Wed, Nov 08, 2006 at 09:46:54PM +0100, Patryk Zawadzki wrote:
> Dnia 08-11-2006, śro o godzinie 20:26 +0100, Jakub Bogusz napisał(a):
> > On Wed, Nov 08, 2006 at 08:21:01PM +0100, Patryk Zawadzki wrote:
> > > Dnia 08-11-2006, śro o godzinie 11:54 +0100, Arkadiusz Miskiewicz
> > > napisał(a):
> > > > On Wednesday 08 November 2006 11:49, Jakub Bogusz wrote:
> > > > > But it tests only IFS compliance.
> > > > > What about all other functionality?
> > > > Haven't seen tests for other functionality.
> > > 
> > > Should we aim at perfect POSIX compatibility or perfect usability? Bash
> > > does not seem to be a heavy dependency and is actively maintained (so
> > > the compatibility issues will go away over time as opposed to pdksh).
> > 
> > And POSIX-compatibility of scripts will go away as nobody will care
> > about.
> 
> To me it sounds similar to the sparc/alpha problem. If someone uses a
> POSIX-only shell (which does not exist), she will complain and things
> will get fixed.
> 
> If noone complains then it is a sign that noone cares and POSIX
> compatibility is done just for the sake of doing it.

Yeah, sure, just like FHS, LSB and so on. Who cares beside few
developers? Why not be just like [put some big vendor name here] and
so on? But... then why be at all?

A script can expect that /bin/sh provides functionality defined by
POSIX, not bash extensions. bash script must use /bin/bash shebang,
period.

You said usability? So OK.
Do some benchmarks. If bash appears to be faster and have lower (or
just insignificantly higher) memory footprint, then it would be good
reason to provide bash as pdksh replacement for /bin/sh. Hint: libtool
scripts used to link some huge libraries (containing many, many
objects) are good stress tests.


-- 
Jakub Bogusz    http://qboosh.cs.net.pl/