Re: ZSH's future - POSIX

Re: ZSH's future - POSIX

[Geoff Wing]

:>> Zoltan Hidvegi(Z) wrote:
:>> 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
:Z> Thanks to Richard, zsh is one of the most portable program I've
:Z> ever seen.  I think ksh could'n beat it.
:Yes, I agree. Richard should take a bow here ;-).
	
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.
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: ZSH's future [longish] ?

[Mark Borges]

Thanks for the comments, Zoltan.

>> On Thu, 26 Oct 1995 16:13:26 +0100 (MET),
>> Zoltan Hidvegi(Z) wrote:

>> 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

Z> Thanks to Richard, zsh is one of the most portable program I've
Z> ever seen.  I think ksh could'n beat it.

Yes, I agree. Richard should take a bow here ;-).

Z> and command line editing is unbeatable.

Yep. zle wins over readline in my book.

>> o Arrays: KSH-93 supports both indexed and associative arrays. The
>> subscript for an indexed array is an arithmetic expression,
>> whereas, the subscript for an associative array is a string.

Z> I think zsh provides all of these array features.  Some of this
Z> code is broken in the baseline version, but I fixed these problems
Z> long ago.

Does zsh support associative arrays?

Z> But it can also be used as a powerful script language.  An example:
Z> with my releases the expansion of ${${(f)$(</etc/group)}%%:*} gives
Z> the list of the group names from /etc/groups.

Uh-oh. If I use the (f) qualifier I only get the first line -- without
it, I get all the group names in a single line separated by
whitespace. A bug in my (old) hzoli version -- 2.6-beta11-test7-hzoli11 --
perhaps? 

Thanks again everyone for the comments. 

Unless I receive some objections, I plan to collect information from
this thread and create a summary article to put on the web site. With
proper credits/acknowledgements, of course.

  -mb-

Re: ZSH's future - POSIX

[Geoff Wing]

:>> Zoltan Hidvegi(Z) wrote:
:>> 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
:Z> Thanks to Richard, zsh is one of the most portable program I've
:Z> ever seen.  I think ksh could'n beat it.
:Yes, I agree. Richard should take a bow here ;-).
	
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.
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: ZSH's future - POSIX

[Richard Coleman]

> > 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