zsh-workers: zsh-3.1.4

zsh-workers: zsh-3.1.4

[Zefram]

-----BEGIN PGP SIGNED MESSAGE-----

Zsh version 3.1.4 has been released, and an announcement posted to
zsh-announce.

For your convenience, the MD5 message digests:
c4c84a4ed2a9817812bb2cf06173ab08  zsh-3.1.3-3.1.4.diff.gz
cda8f4ff5f9a3822d08600180fb67922  zsh-3.1.4-doc.tar.gz
bcf3e6423262b0d0418ebdd5c86b1bf7  zsh-3.1.4.tar.gz

I wasn't able to put in all the patches I wanted to in this release.
My development machine is on its last elbows, such that over the last
couple of days gcc was hitting a memory error every other compile.
I thought it better to release now, rather than wait until I get a new
machine, in order to have a release with the configure bug fixed.

Some significant patches NOT included in 3.1.4 are:

3933  Dynamic loading on AIX
    No objection in principle, but I want the .export lists to be
    generated automatically.  I was going to add a "#define mod_export"
    into zsh.h, and have makepro.awk add to the export lists any symbols
    declared using this pseudo-keyword.  As I said, practical problems
    prevented me from doing this.

3950  set blocking read on stdin
    I'm rather dubious about this EWOULDBLOCK business.  I think this
    should be EAGAIN.  I'm also a bit suspicious about where the blocking
    status is being changed, but I haven't examined it in detail yet.

3969  fix spaceinline() to fix yank
    I think spaceinline() already has the correct behaviour, and
    callers that invoke the boundary case should explicitly implement
    the behaviour they actually want.

3983  exporting unset special parameters
    I wanted to do this properly, to get consistent behaviour.
    Practical problems again.

3990  PWD parameter
    Not decided what the correct behaviour is.  It might be good to aim
    for the pure sh/ksh situation of having no actual special parameters
    (in the zsh sense) when in sh/ksh mode.

 -zefram

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: ascii

iQEVAwUBNXFxTJmk9GeOHh7BAQFWFQf+IrGpNWXTBr9xm6JSrsQ3cToeXgQ6d0ll
cMg3XxpsWmWEBdtea70R4r3ZARelE1/CHaMfU8pmHawvGb4jG+rpEgAkeu5QeG97
tuwaKt3RfYR0akZctvWhTccT7/k1lyTPdMffTO9KLAQAU2bg3wwI2BV+apFFh8q/
LM0x6YsEmJNWDKDz0W3MjLTwtn9/QmseyZvUwWFfTSAhKZIiHMx0PBvEYQhTj4Ag
0tclB3oCEXLlEWwQs+WuS5AfNgvbvAu4zvPb6PIl3xAEb8iqUSXB6WcHJZpuE8OT
RkQvZ8WXmoPLryiBCK1ytTZQquXVO82wtF/9y5TINTRuwoKscT22Kg==
=T4gX
-----END PGP SIGNATURE-----

Re: zsh-workers: zsh-3.1.4

[Bart Schaefer]

A couple of build oddities (on RedHat 4.2 Linux):

"make clean" fails when /bin/sh is bash because $(SUBDIRS) is empty in
Doc and Etc and maybe elsewhere.  Bash gets a syntax error at

	for subdir in ; do

even though that is prefixed with "if test -n '$(SUBDIRS)'" because it
apparently wants to parse the entire line before executing any of it.

The above is an additional problem because following a configure with
--enable-dynamic, it's necessary to "make clean" in order to get a
successful compile using --disable-dynamic.  Reconfiguring with dynamic
disabled without first doing a "make clean" causes some of the sed
replacements on the Makefiles to fail, and make produces weird errors
like

	g: command not found (ignored)

(Actually, it may fail that way even with a "make clean", because after
discovering the reason "make clean" was failing I resorted to "rm -r"
and then reconfigured.)

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

Re: zsh-workers: zsh-3.1.4

[Zefram]

Bart Schaefer wrote:
>"make clean" fails when /bin/sh is bash because $(SUBDIRS) is empty in
>Doc and Etc and maybe elsewhere.  Bash gets a syntax error at
>
>	for subdir in ; do
>
>even though that is prefixed with "if test -n '$(SUBDIRS)'" because it
>apparently wants to parse the entire line before executing any of it.

Cool.  I guess we'll have to go back to one of the other (less neat)
mechanisms.  Simple fix:

	subdirs='$(SUBDIRS)'; for subdir in $$subdirs; do ...

-zefram

Re: zsh-workers: zsh-3.1.4

[Timothy J Luoma]

	Author:        "Bart Schaefer" <schaefer@brasslantern.com>
	Original-Date: Mon, 1 Jun 1998 08:56:34 -0700
	Message-ID:    <980601085634.ZM26365@candle.brasslantern.com>

> A couple of build oddities (on RedHat 4.2 Linux):
>
> "make clean" fails when /bin/sh is bash because $(SUBDIRS) is empty in
> Doc and Etc and maybe elsewhere.  Bash gets a syntax error at

Yet another reason, is it not, why /bin/sh should be /bin/sh and not  
/bin/something-that-wants-to-pretend-it-is-sh ????

TjL, still wondering why people fix things that aren't broken

Re: zsh-workers: zsh-3.1.4

[Bart Schaefer]

On Jun 1, 12:33pm, Timothy J Luoma wrote:
} Subject: Re: zsh-workers: zsh-3.1.4
}
} > "make clean" fails when /bin/sh is bash because $(SUBDIRS) is empty in
} > Doc and Etc and maybe elsewhere.  Bash gets a syntax error at
} 
} Yet another reason, is it not, why /bin/sh should be /bin/sh and not  
} /bin/something-that-wants-to-pretend-it-is-sh ????

Unfortunately, there's no (?) PD implementation of the pure old-fashioned
Bourne shell that can be distributed with Linux.  It's either pretend, or
don't have a /bin/sh at all, I think.

That said, I'm not entirely sure that the Bourne shell wouldn't also have
choked on that construct.  My guess is it was tested with zsh and ksh,
not with a "real" sh.

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

Re: zsh-workers: zsh-3.1.4

[Zoltan Hidvegi]

> } Yet another reason, is it not, why /bin/sh should be /bin/sh and not  
> } /bin/something-that-wants-to-pretend-it-is-sh ????

Bash and zsh are real enough for me.  /bin/sh is /bin/sh no matter if
it's bash or zsh :-).  And if something does not work when /bin/sh is
a copy of zsh, than it is probably a zsh bug, and we'll fix it, right?
But how can I fix the old Bourne Shell for which I have no source?

> Unfortunately, there's no (?) PD implementation of the pure old-fashioned
> Bourne shell that can be distributed with Linux.  It's either pretend, or
> don't have a /bin/sh at all, I think.

ash is quite close.  You'd still need to remove some features from ash
to get a real old-fashionned shell.

> That said, I'm not entirely sure that the Bourne shell wouldn't also have
> choked on that construct.  My guess is it was tested with zsh and ksh,
> not with a "real" sh.

Actually, zsh is probably the only shell which does not choke on

for i in ; do echo hehe; done

But as long as it affects only make clean, it is not that bad as the
configure bug in 3.1.3 was.

Zoli

Re: zsh-workers: zsh-3.1.4

[Wayne Davison]

Zefram writes:
> 3969  fix spaceinline() to fix yank
>     I think spaceinline() already has the correct behaviour, and
>     callers that invoke the boundary case should explicitly implement
>     the behaviour they actually want.

No, spaceinline() is definitely broken.  To see this, it is only
necessary to set the point and type some characters.  The easiest
way to do this is to start with an empty line (which has the point
set to the start of the line), type a few characters, and type Ctrl-X
Ctrl-X -- the curor doesn't budge (it should have gone to the start
of the line).  That's because spaceinline() keeps bumping the point
forward when it shouldn't.

Having a >= in spaceinline() is wrong -- it should be just >.

..wayne..

Re: zsh-workers: zsh-3.1.4

[Zefram]

Timothy J Luoma wrote:
>Yet another reason, is it not, why /bin/sh should be /bin/sh and not  
>/bin/something-that-wants-to-pretend-it-is-sh ????

No, plenty of `real' sh's choke on that construct.  We cater to
idiosyncracies of Bourne shell variants right back to V6 (hence no shell
functions); bash now counts as such a variant, though it doesn't seem
to have any special restrictions not present in any earlier sh.

>TjL, still wondering why people fix things that aren't broken

With me, it's a case of "I know it works in practice, but does it work
in theory?".

-zefram

Re: zsh-workers: zsh-3.1.4

[Zefram]

Wayne Davison wrote:
>No, spaceinline() is definitely broken.  To see this, it is only
>necessary to set the point and type some characters.  The easiest
>way to do this is to start with an empty line (which has the point
>set to the start of the line), type a few characters, and type Ctrl-X
>Ctrl-X -- the curor doesn't budge (it should have gone to the start
>of the line).  That's because spaceinline() keeps bumping the point
>forward when it shouldn't.
>
>Having a >= in spaceinline() is wrong -- it should be just >.

So the mark should be attached to the preceding character, rather than the
following?  If that is the correct semantic then spaceinline() is broken.

-zefram

Re: zsh-workers: zsh-3.1.4

[Bart Schaefer]

On Jun 2,  8:31am, Zefram wrote:
} Subject: Re: zsh-workers: zsh-3.1.4
}
} So the mark should be attached to the preceding character, rather than the
} following?  If that is the correct semantic then spaceinline() is broken.

I don't know if "attached to the preceding character" is the right way to
think about it or not.  However, when mark is equal to point and then
additional characters are inserted, the mark should definitely be "left
behind" as point moves away.

I believe I remarked upon this once before ... ah, yes:

http://www.zsh.org/mla/users-1997-hyper/0577.html
http://www.zsh.org/mla/users-1997-hyper/0579.html
http://www.zsh.org/mla/users-1997-hyper/0582.html

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

Re: zsh-workers: zsh-3.1.4

[Chet Ramey]

> "make clean" fails when /bin/sh is bash because $(SUBDIRS) is empty in
> Doc and Etc and maybe elsewhere.  Bash gets a syntax error at
> 
> 	for subdir in ; do
> 
> even though that is prefixed with "if test -n '$(SUBDIRS)'" because it
> apparently wants to parse the entire line before executing any of it.

Yes, this is how sh is supposed to work.  A real, honest-to-god Bourne
shell (SunOS 4.1.4) does not accept an empty list after `in' either.

odin(3)$ sh
${HOST}($SHLVL)\$ for x in ; do echo z ; done
syntax error: `;' unexpected
${HOST}($SHLVL)\$ if test -n ''
> then
> for x in ; do echo z ; done
syntax error: `;' unexpected


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

blocking read stdin patch (Re: zsh-workers: zsh-3.1.4)

[yamagata]

Hello,

In message <199806010819.JAA27897@diamond.tao.co.uk>,
Zefram wrote
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Zsh version 3.1.4 has been released, and an announcement posted to
> zsh-announce.

(snip)

> 3950  set blocking read on stdin
>     I'm rather dubious about this EWOULDBLOCK business.  I think this
>     should be EAGAIN.  I'm also a bit suspicious about where the blocking
>     status is being changed, but I haven't examined it in detail yet.

(snip)

In 4.2BSD, non-blocking read will be return by EWOULDBLOCK,
But in POSIX it should be EAGAIN.

Some OS (like SunOS4.1.X or Ultrix) may return both error.
It seems to be decided by compile environment
or what flag was used for blocking read.

In SunOS 4.1.X,
When set O_NONBLOCK, will be EWOULDBLOCK,
When set O_NDELAY, will be EAGAIN.

In 4.4BSD and Digital UNIX(3.2 and 4.0),
EWOULDBLOCK and EAGAIN are same value,
thus Zoltan's patch works fine.

				yamagata