posix compliance

posix compliance

[Clint Adams]

The beginnings of a POSIX-compliance test suite are at
http://people.debian.org/~schizo/ , if anyone's interested.

Currently zsh performs better than Debian's ash.

Re: posix compliance

[Jos Backus]

A quick report from UseNIX: One thing Jordan Hubbard of Apple mentioned was
that our positional parameters ($1, $2, etc.) are assignable whereas they are
not in bash (Chet Ramey, who was also present, confirmed this). The bash
behavior is apparently what POSIX specifies. This was one of the things which
kept Apple from keeping zsh as their /bin/sh, according to him.  Personally I
thought his defense was rather weak: they tested with 3.0.8 and didn't bother
to give the zsh developers any feedback. He also again complained about
executable size and footprint (zsh vs. bash), which I think was addressed
earlier without them giving us any feedback.

Otoh, the next version of OS X will have an updated zsh 4.0.4.

-- 
Jos Backus                 _/  _/_/_/        Santa Clara, CA
                          _/  _/   _/
                         _/  _/_/_/             
                    _/  _/  _/    _/
jos@catnook.com     _/_/   _/_/_/            require 'std/disclaimer'

Re: posix compliance

[Bart Schaefer]

On Thu, 20 Jun 2002, Jos Backus wrote:

> A quick report from UseNIX: One thing Jordan Hubbard of Apple mentioned was
> that our positional parameters ($1, $2, etc.) are assignable whereas they are
> not in bash (Chet Ramey, who was also present, confirmed this). The bash
> behavior is apparently what POSIX specifies.

Assignable positional parameters are an intentional feature.  There's no
way they can cause a problem, because a POSIX conforming shell script must
not even attempt it.  (Even in POSIX the positional parameters can be
replaced with the `set' builtin, so claiming that they should be read-only
does not hold water.)

> He also again complained about executable size and footprint (zsh vs.
> bash), which I think was addressed earlier

I don't have an immediate answer to that, although having looked briefly
at the bash2 web site the other day and it's possible that it now has even
more of its "builtins" as loadable modules than zsh does.

Re: posix compliance

[Jos Backus]

On Thu, Jun 20, 2002 at 11:13:43AM -0700, Bart Schaefer wrote:
> Assignable positional parameters are an intentional feature.  There's no
> way they can cause a problem, because a POSIX conforming shell script must
> not even attempt it.  (Even in POSIX the positional parameters can be
> replaced with the `set' builtin, so claiming that they should be read-only
> does not hold water.)

Indeed, his argument that things like these were causing them lots of problems
with zsh point to poorly written scripts in the first place. But of course
he's not going to admit that, least of all in public with the bash maintainer
standing next to him.

-- 
Jos Backus                 _/  _/_/_/        Santa Clara, CA
                          _/  _/   _/
                         _/  _/_/_/             
                    _/  _/  _/    _/
jos@catnook.com     _/_/   _/_/_/            require 'std/disclaimer'

Re: posix compliance

[Dan Nelson]

In the last episode (Jun 20), Jos Backus said:
> On Thu, Jun 20, 2002 at 11:13:43AM -0700, Bart Schaefer wrote:
> > Assignable positional parameters are an intentional feature. 
> > There's no way they can cause a problem, because a POSIX conforming
> > shell script must not even attempt it.  (Even in POSIX the
> > positional parameters can be replaced with the `set' builtin, so
> > claiming that they should be read-only does not hold water.)
> 
> Indeed, his argument that things like these were causing them lots of
> problems with zsh point to poorly written scripts in the first place.
> But of course he's not going to admit that, least of all in public
> with the bash maintainer standing next to him.

The only reason I can think of to disallow non-POSIX-sanctioned
behvaiour is to prevent the rampant use of such features, as has
already happened in the Linux "sh == bash" world.  You could even make
the case that zsh in sh emulation mode should allow only what POSIX
says it can do and nothing more.

If we're talking about zsh mode, then I lean the other way and say zsh
can do whatever it wants, as long as what POSIX mandates it does a
certain way, it does.

-- 
	Dan Nelson
	dnelson@allantgroup.com

RE: posix compliance

[Borsenkow Andrej]

> A quick report from UseNIX: One thing Jordan Hubbard of Apple
mentioned was
> that our positional parameters ($1, $2, etc.) are assignable whereas
they
> are
> not in bash (Chet Ramey, who was also present, confirmed this). The
bash
> behavior is apparently what POSIX specifies.

It depends.

SUS V3 (which I hope is quite reliable representation of POSIX) says
that interpretation of

WORD1=WORD2

where WORD1 is not a name is implementation defined. It may be legally
interpreted as assignment.


You are correct that in case of ${WORD1=WORD2} it is prohibited:

${parameter:=word} 
Assign Default Values. If parameter is unset or null, the expansion of
word shall be assigned to parameter. In all cases, the final value of
parameter shall be substituted. Only variables, not positional
parameters or special parameters, can be assigned in this way.

In case of read built-in it is unclear. There are no explicit
restrictions; one may infer that special parameters are invalid only
from this line:

var 
The name of an existing or nonexisting shell variable.

and only due to usage of "name" here.


-andrej

Re: posix compliance

[Oliver Kiddle]

On 20 Jun, you wrote:
> A quick report from UseNIX: One thing Jordan Hubbard of Apple mentioned was

Thanks for the update.

> Otoh, the next version of OS X will have an updated zsh 4.0.4.

I wonder if the issue I mentioned in 16853 is going to be a problem for
them then. We ought to come up with a quick fix for 4.0. I'm off on
holiday midway through next week and have a lot of work to finish before
so I can't do anything quick.

I'll be interested to see what these updates are. I'm guessing that
they've cut out a few modules and completion stuff.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: posix compliance

[Bart Schaefer]

On Jun 21, 12:35pm, Oliver Kiddle wrote:
} Subject: Re: posix compliance
}
} I wonder if the issue I mentioned in 16853 is going to be a problem for
} them then. We ought to come up with a quick fix for 4.0.

This seems to handle it nicely: only add all the predefined autoloads
when starting up in zsh emulation.  Everything works as usual for any
explicit autoloads set up with zmodload.

Index: Src/mkbltnmlst.sh
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Src/mkbltnmlst.sh,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mkbltnmlst.sh
--- Src/mkbltnmlst.sh	9 Apr 2001 20:14:12 -0000	1.1.1.1
+++ Src/mkbltnmlst.sh	23 Jun 2002 17:43:19 -0000
@@ -20,6 +20,7 @@
 
 exec > $1
 
+echo "  if (emulation == EMULATE_ZSH) {"
 for x_mod in $x_mods; do
     modfile="`grep '^name='$x_mod' ' $CFMOD | sed -e 's/^.* modfile=//' \
       -e 's/ .*//'`"
@@ -60,6 +61,7 @@
     done
     test "x$linked" = xno && echo "#endif"
 done
+echo "  }"
 
 echo
 done_mods=" "

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: posix compliance

[Jos Backus]

    Hi Chet,

[T'was nice to meet you, btw.]

On Thu, Jun 20, 2002 at 05:19:24PM -0400, Chet Ramey wrote:
> > Indeed, his argument that things like these were causing them lots of
> > problems with zsh point to poorly written scripts in the first place. But
> > of course he's not going to admit that, least of all in public with the
> > bash maintainer standing next to him.
> 
> Oh, I wouldn't have minded.  There's a lot of crap out there, and shell
> scripts are no exception.

Absolutely. I just wish that he had been interested in discussing the real
problems they were undoubtedly having with zsh so they can be fixed; that's
how progress is made.

> ( ``Discere est Dolere'' -- chet)

"Learning is suffering"? My Latin is rusty.

-- 
Jos Backus                 _/  _/_/_/        Santa Clara, CA
                          _/  _/   _/
                         _/  _/_/_/             
                    _/  _/  _/    _/
jos@catnook.com     _/_/   _/_/_/            require 'std/disclaimer'

Re: posix compliance

[Chet Ramey]

> Indeed, his argument that things like these were causing them lots of problems
> with zsh point to poorly written scripts in the first place. But of course
> he's not going to admit that, least of all in public with the bash maintainer
> standing next to him.

Oh, I wouldn't have minded.  There's a lot of crap out there, and shell
scripts are no exception.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/