5.3.1

5.3.1

[Peter Stephenson]

You can find version 5.3.1 of zsh at http://www.zsh.org/pub and at
Sorceforge --- except for the gzip version at www.zsh.org, which is slow
arriving.  I'll update the other links if that arrives in time.

The changes from 5.3 are mostly minor; this fixes  "printf -" so it
outputs a "-".

pws

Re: 5.3.1

[Ray Andrews]

On 21/12/16 12:07 PM, Peter Stephenson wrote:
> The changes from 5.3 are mostly minor; this fixes  "printf -" so it
> outputs a "-".
>
> pws
>
**************************************
47 successful test scripts, 0 failures, 1 skipped
**************************************

... even running as root  :-)

Re: 5.3.1

[Ray Andrews]

On 21/12/16 01:57 PM, Ray Andrews wrote:
>
> ... even running as root  :-)
>
>
>
One glitch, 'command not found: zcurses'.

But I installed ncurses-dev as always and there was no complaint.

Re: 5.3.1

[Bart Schaefer]

On Wed, Dec 21, 2016 at 2:54 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> One glitch, 'command not found: zcurses'.

Check your config.modules file.  zcurses is not an autoloaded builtin,
so you have to zmodload zsh/cursers first unless you've edited
config.modules to have it load that module by default.

Re: 5.3.1

[Ray Andrews]

On 21/12/16 03:07 PM, Bart Schaefer wrote:
> On Wed, Dec 21, 2016 at 2:54 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> One glitch, 'command not found: zcurses'.
> Check your config.modules file.  zcurses is not an autoloaded builtin,
> so you have to zmodload zsh/cursers first unless you've edited
> config.modules to have it load that module by default.
>
No luck.  I do this:


     name=zsh/curses modfile=Src/Modules/curses.mdd link=dynamic 
auto=yes load=yes

but every time I run configure, it puts it back to stock:

     name=zsh/curses modfile=Src/Modules/curses.mdd link=no auto=yes load=no

This looks ok, from the configure output:

    checking ncurses.h usability... yes
    checking ncurses.h presence... yes
    checking for ncurses.h... yes
    checking ncursesw/ncurses.h usability... no
    checking ncursesw/ncurses.h presence... no
    checking for ncursesw/ncurses.h... no
    checking ncurses/ncurses.h usability... no
    checking ncurses/ncurses.h presence... no
    checking for ncurses/ncurses.h... no

But this is is more ominous:

     checking if we need to ignore ncurses... yes

I have a vague memory of having had this problem before but my notes on 
the issue are lost.

Re: 5.3.1

[Bart Schaefer]

On Dec 21,  3:53pm, Ray Andrews wrote:
} Subject: Re: 5.3.1
}
}      name=zsh/curses modfile=Src/Modules/curses.mdd link=dynamic 
} auto=yes load=yes
} 
} but every time I run configure, it puts it back to stock

Yes, you need to (in this order)

configure
edit config.modules
make

I keep an edited copy of config.modules named config.modules.local
so the "edit config.modules" step becomes

cp config.module.local config.modules


Did you try zmodload zsh/curses ?  If you have 47 tests passing with
only one skipped, the module probably is built and is linkable, unless
that IS the one that got skipped (for me it's always zsh/pcre skipped).

Re: 5.3.1

[Ray Andrews]

On 21/12/16 04:12 PM, Bart Schaefer wrote:
> On Dec 21,  3:53pm, Ray Andrews wrote:
> } Subject: Re: 5.3.1
> }
> }      name=zsh/curses modfile=Src/Modules/curses.mdd link=dynamic
> } auto=yes load=yes
> }
> } but every time I run configure, it puts it back to stock
>
> Yes, you need to (in this order)
>
> configure
> edit config.modules
> make
>
> I keep an edited copy of config.modules named config.modules.local
> so the "edit config.modules" step becomes
>
> cp config.module.local config.modules

No luck Bart. Did it exactly so except :


     ./configure --prefix=/aWorking/zsh-5.3.1/Build

... which I trust should be ok. And it's always worked before. However 
it did not overwrite the file so, that's progress.
>
> Did you try zmodload zsh/curses ?

     $ /aWorking/zsh-5.3.1 6$ zmodload zsh/curses
     zsh: failed to load module `zsh/curses': 
/aWorking/zsh-5.3.1/Build/lib/zsh/5.3.1/zsh/curses.so: undefined symbol: 
     COLORS

>   If you have 47 tests passing with
> only one skipped, the module probably is built and is linkable, unless
> that IS the one that got skipped (for me it's always zsh/pcre skipped).
>
But these are found:


./Modules/curses.pro
./Modules/curses.epro
./Modules/curses.mdhi
./Modules/curses.c
./Modules/curses.so
./Modules/curses..o
./Modules/curses_keys.awk
./Modules/curses.mdd
./Modules/curses.mdhs
./Modules/curses_keys.h
./Modules/curses.export
./Modules/curses.syms
./Modules/curses.mdh
./zshcurses.h

Re: 5.3.1

[Ray Andrews]

On 21/12/16 04:40 PM, Ray Andrews wrote:
>
>     $ /aWorking/zsh-5.3.1 6$ zmodload zsh/curses
>     zsh: failed to load module `zsh/curses': 
> /aWorking/zsh-5.3.1/Build/lib/zsh/5.3.1/zsh/curses.so: undefined 
> symbol:     COLORS

Yet, the module seems to be there, exactly as before:

1 /aWorking/zsh-5.3.1/Build/lib/zsh/5.3.1/zsh 8$ l

drwxr-xr-x 2   4096 2016-12-21_16:28:22 param/
drwxr-xr-x 2   4096 2016-12-21_16:28:22 net/
-rwxr-xr-x 1  18904 2016-12-21_16:28:22 rlimits.so*
-rwxr-xr-x 1  10712 2016-12-21_16:28:22 sched.so*
-rwxr-xr-x 1  10768 2016-12-21_16:28:22 attr.so*
-rwxr-xr-x 1   6448 2016-12-21_16:28:22 cap.so*
-rwxr-xr-x 1  10544 2016-12-21_16:28:22 clone.so*
-rwxr-xr-x 1  36440 2016-12-21_16:28:22 curses.so*
-rwxr-xr-x 1  10904 2016-12-21_16:28:22 datetime.so*
-rwxr-xr-x 1  11024 2016-12-21_16:28:22 example.so*
-rwxr-xr-x 1  19952 2016-12-21_16:28:22 files.so*
-rwxr-xr-x 1  11120 2016-12-21_16:28:22 langinfo.so*
-rwxr-xr-x 1  10640 2016-12-21_16:28:22 mapfile.so*
-rwxr-xr-x 1  21872 2016-12-21_16:28:22 mathfunc.so*
-rwxr-xr-x 1   6176 2016-12-21_16:28:22 newuser.so*
-rwxr-xr-x 1  41248 2016-12-21_16:28:22 parameter.so*
-rwxr-xr-x 1  10536 2016-12-21_16:28:22 regex.so*
-rwxr-xr-x 1  14920 2016-12-21_16:28:22 stat.so*
-rwxr-xr-x 1  24680 2016-12-21_16:28:22 system.so*
-rwxr-xr-x 1  10608 2016-12-21_16:28:22 termcap.so*
-rwxr-xr-x 1  10608 2016-12-21_16:28:22 terminfo.so*
-rwxr-xr-x 1  45072 2016-12-21_16:28:22 zftp.so*
-rwxr-xr-x 1  10544 2016-12-21_16:28:22 zprof.so*
-rwxr-xr-x 1  19088 2016-12-21_16:28:22 zpty.so*
-rwxr-xr-x 1  10576 2016-12-21_16:28:22 zselect.so*
-rwxr-xr-x 1  31568 2016-12-21_16:28:22 zutil.so*
-rwxr-xr-x 1  64592 2016-12-21_16:28:22 compctl.so*
-rwxr-xr-x 1 149056 2016-12-21_16:28:22 complete.so*
-rwxr-xr-x 1  64616 2016-12-21_16:28:22 complist.so*
-rwxr-xr-x 1  68880 2016-12-21_16:28:22 computil.so*
-rwxr-xr-x 1  10312 2016-12-21_16:28:22 deltochar.so*
-rwxr-xr-x 1 330592 2016-12-21_16:28:22 zle.so*
-rwxr-xr-x 1  10600 2016-12-21_16:28:22 zleparameter.so*

Re: 5.3.1

[Bart Schaefer]

On Dec 21,  4:40pm, Ray Andrews wrote:
} 
}      $ /aWorking/zsh-5.3.1 6$ zmodload zsh/curses
}      zsh: failed to load module `zsh/curses': 
} /aWorking/zsh-5.3.1/Build/lib/zsh/5.3.1/zsh/curses.so: undefined symbol: 
}      COLORS

Well, obviously configure has correctly decided ("link=no" in unedited
config.modules) that whatever curses library it has found on its own
will not properly link the curses.so file.

Try

    LIBS=-lncurses configure ...

If that doesn't work, you'll have to figure out what library to link with
to get the COLORS symbol, because it's obviously declared extern in some
header that the compiler is finding when you "make".

Re: 5.3.1

[Ray Andrews]

On 21/12/16 07:03 PM, Bart Schaefer wrote:
>      LIBS=-lncurses configure ...
Pardon Bart I don't know what you mean there. Is that two commands? 
'configure' must come first, no?

Re: 5.3.1

[Jérémie Roquet]

Hi Ray,

2016-12-22 4:42 GMT+01:00 Ray Andrews <rayandrews@eastlink.ca>:
> On 21/12/16 07:03 PM, Bart Schaefer wrote:
>>
>>      LIBS=-lncurses configure ...
>
> Pardon Bart I don't know what you mean there. Is that two commands?
> 'configure' must come first, no?

The “VAR=VALUE COMMAND” syntax sets the VAR environment variable to
the VALUE value while running the COMMAND command, and only while
running it. Here, it's almost the same as setting “LIBS=-lncurses”
then running “configure”, except that right after executing, “LIBS” is
still unset.

Best regards,

-- 
Jérémie

Re: 5.3.1

[Ray Andrews]

On 21/12/16 08:08 PM, Jérémie Roquet wrote:
> Hi Ray,
>
> The “VAR=VALUE COMMAND” syntax sets the VAR environment variable to
> the VALUE value while running the COMMAND command, and only while
> running it. Here, it's almost the same as setting “LIBS=-lncurses”
> then running “configure”, except that right after executing, “LIBS” is
> still unset.
>
> Best regards,
>
Thanks Jérémie, I've never seen that before.


Anyway, all good, the necessary lib is 'libncursesw5-dev' and don't 
forget the 'w' :(

I guess that just remained installed for all previous builds before the 
64 bit Debian, so I just plumb forgot about it.  It doesn't help that 
Debian offers 20 different libraries around the 'curses' theme and you 
hafta pick the right one.   I'll tattoo it onto my forearm.  Thanks 
Bart, without your advice I wouldn't have had a prayer of figuring that out.

Re: 5.3.1

[Daniel Shahaf]

Ray Andrews wrote on Wed, Dec 21, 2016 at 20:59:28 -0800:
> Anyway, all good, the necessary lib is 'libncursesw5-dev' and don't forget
> the 'w' :(

For future reference, you can run
.
    apt-get build-dep zsh
.
to install everything required to build zsh.

Note this will install optional dependencies too.

Cheers,

Daniel

Re: 5.3.1

[Ray Andrews]

On 22/12/16 03:57 AM, Daniel Shahaf wrote:
> Ray Andrews wrote on Wed, Dec 21, 2016 at 20:59:28 -0800:
>> Anyway, all good, the necessary lib is 'libncursesw5-dev' and don't forget
>> the 'w' :(
> For future reference, you can run
> .
>      apt-get build-dep zsh
> .
> to install everything required to build zsh.
>
> Note this will install optional dependencies too.

Marvellous.  Five years kicking around in Linux and I only learn this 
now.  I always thought that 'install' would handle whatever was required 
but that would be too easy.  Thank you sensei.

Mind ... it did work anyway as installed from Debian, the trouble was 
only when building from sources and I suppose that without the specific 
massaging of a Debian package, Peter's sources would have no way of 
knowing what any particular extra stuff might be needed in any given 
environment (and this issue is mentioned in the notes), so no foul *but* 
I could look at the files downloaded by the above and that would clue me 
in to the name of the necessary extra packages, so this 'build-dep' is 
still manna from heaven.

BTW, why is it that an edit of 'config.modules' is always quietly 
overwritten by the installer?  Why does it not feel that it can let me 
have my preferences as to which modules are built the way I want them?  
Bart showed how to get around that, but why do we need trickery?

Re: 5.3.1

[Bart Schaefer]

On Dec 22,  8:03am, Ray Andrews wrote:
} Subject: Re: 5.3.1
}
} Marvellous.  Five years kicking around in Linux and I only learn this 
} now.

apt-get build-dep is a Debian thing, not a Linux thing in general.

} BTW, why is it that an edit of 'config.modules' is always quietly 
} overwritten by the installer?

It's not overwritten by "the installer".  It has a dependency on the
files generated by the "configure" script, so it will only be remade
if configure has been re-run.  Normally this happens during the
execution of configure itself, so any edits to config.modules that
you do will cause config.modules to be newer than its dependencies,
and it will not be rebuilt.

If configure is running, the assumption is that preconditions for the
build have changed, so config.modules is regenerated from the defaults
in Src/**/*.mdd files.  This is also how new modules are picked up.

You aren't supposed to need to run "configure" more than once on the
same build tree unless something about the preconditions is changing.
If you are routinely re-running configure when none of the templates
from which it is built (e.g. configure.ac) has changed, you're doing
more work than necessary.

Anyway, if you actually read either the INSTALL file or the comments
in config.modules itself:

# Values of `auto' are `yes' or `no'. configure sets the value to
# `yes'.  If you set it by hand to `no', the line will be retained
# when the file is regenerated in future.

I should have remembered that.  I've forgotten why I stopped using it
and went with a local copy ... probably because for quite a while I
was switching back and forth between static and dynamic linking on
a regular basis and needed two copies of the file to do so.

Re: 5.3.1

[Ray Andrews]

On 22/12/16 01:40 PM, Bart Schaefer wrote:
> On Dec 22,  8:03am, Ray Andrews wrote:
> } Subject: Re: 5.3.1
> }
> } Marvellous.  Five years kicking around in Linux and I only learn this
> } now.
>
> apt-get build-dep is a Debian thing, not a Linux thing in general.

Sure.  These competing package managers all have their own ideas.
>
> } BTW, why is it that an edit of 'config.modules' is always quietly
> } overwritten by the installer?
>
> It's not overwritten by "the installer".  It has a dependency on the
> files generated by the "configure" script, so it will only be remade
> if configure has been re-run.  Normally this happens during the
> execution of configure itself, so any edits to config.modules that
> you do will cause config.modules to be newer than its dependencies,
> and it will not be rebuilt.

Rather in the style of 'make' itself.  So in my case, the wiping out of 
my edits
can be considered as a report that the module was not built, yes?
>
> If configure is running, the assumption is that preconditions for the
> build have changed, so config.modules is regenerated from the defaults
> in Src/**/*.mdd files.  This is also how new modules are picked up.
>
> You aren't supposed to need to run "configure" more than once on the
> same build tree unless something about the preconditions is changing.
> If you are routinely re-running configure when none of the templates
> from which it is built (e.g. configure.ac) has changed, you're doing
> more work than necessary.
Good to know.  Yes, I have tended to do it every time for lack of 
knowing that I don't
need to.  I'm also unclear as to 'make' and 'make install' so again I do 
them both.
>
> Anyway, if you actually read either the INSTALL file or the comments
> in config.modules itself:
>
> # Values of `auto' are `yes' or `no'. configure sets the value to
> # `yes'.  If you set it by hand to `no', the line will be retained
> # when the file is regenerated in future.

Before yesterday I didn't really expect things to be overwritten anyway, 
so I took the
'retained' as meaning 'autoload'.   INSTALL is rather intimidating if 
one simply wants
a plain vanilla situation.  You have to already be an expert to really 
understand it.  Typical of 'nix
culture tho, the docs are a summary of the knowledge of the expert 
written for others
exactly like himself and not much use to people who don't already 
understand everything
that's in it.  zsh no more hierographic than any other tho.
>
> I should have remembered that.  I've forgotten why I stopped using it
> and went with a local copy ... probably because for quite a while I
> was switching back and forth between static and dynamic linking on
> a regular basis and needed two copies of the file to do so.
>
It is comforting to know that even you forget some of this stuff, I 
don't feel quite so stupid.

Re: 5.3.1

[Simon Ruderich]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Wed, Dec 21, 2016 at 08:07:58PM +0000, Peter Stephenson wrote:
> You can find version 5.3.1 of zsh at http://www.zsh.org/pub and at
> Sorceforge --- except for the gzip version at www.zsh.org, which is slow
> arriving.  I'll update the other links if that arrives in time.

Hello,

I've updated the website [1] for this release. The commits are in
the public web repository [2] (75577c4; tag zsh-5.3.1). If you find
any problems/mistakes please tell me.

Regards
Simon

[1]: http://zsh.sourceforge.net/
[2]: http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/web;a=summary
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 5.3.1

[Peter Stephenson]

On Tue, 3 Jan 2017 13:48:02 +0100
Simon Ruderich <simon@ruderich.org> wrote:
> I've updated the website [1] for this release. The commits are in
> the public web repository [2] (75577c4; tag zsh-5.3.1). If you find
> any problems/mistakes please tell me.

Thanks!
pws