Re: ZSH's future - POSIX

[Richard Coleman <coleman@xxxxxxxxxxxxxxx>]

> > The code should conform to the IEEE POSIX 1003.1 standard and to
> > the proposed ANSI-C standard so that it should be portable to all
> > such
> 	
> I seem to remember there was a problem with some of the stat() and associated
> stuff.  Mainly because POSIX doesn't support all the S_I*() stuff used.
> There would need to be a large rewrite of one part of code to make it fully
> POSIX compatible.  One really big drawback with POSIX compatibility is its
> lack of support for things like symbolic-links, sockets, etc.

There are two notions of POSIX compatibility here.

The first is whether the code itself uses only POSIX features.  Zsh is
fairly good in this respect.  This was one of the reasons I rewrote the
signals code a while back.  But I don't think zsh would compile in a strict
POSIX environment.  Most of the problems would probably be because zsh
assumes the existentence of things not covered in the POSIX standard,
but available on most all unix machines (such as symbolic links).
This could probably be easily fixed if necessary, but I don't really
see the need for this.  If every vendor supports a feature, then it is
standard enough for me.  The goal after all is portability.

The second is whether zsh comforms to the POSIX standard concerning
shell syntax.  I believe this was what the ksh literature for ksh93
was referring to.  I believe ksh93 is supposed to be a conforming
superset of the POSIX shell standard.  I assume that zsh doesn't
conform to this standard.  It might be worth investigating what
parts of zsh don't conform.

rc