zsh 5.1 released [user]

zsh 5.1 released [user]

[Peter Stephenson]

[You may or may not also get this from zsh-announce@zsh.org, but this is
likely to arrive more quickly in any case so I thought I'd send it here.  Do
not ingest your SATS.]

Version 5.1 of zsh has been released and is available from

http://www.zsh.org/pub/

and will be uploaded to Sourceforge.

Note that in addition to the tar.gz files (for people who like
traditional compression schemes) there are also tar.xz rather than
tar.bz2 files (for people how like the latest compression scheme).
The latter are uncompressed with "tar xJf", rather than "tar xjf".

This is an upgrade from 5.0.8.  A two-digit release number has been
picked as a simplification: it does not imply that this version is
substantially different from the previous release.

There are a couple of interesting enhancements.  In particular, there is
now support for genuine assignment syntax after keywords such as "local"
and "typeset"

Also, text pased within X terminals is safer as it appears as characters
rather than raw input (so in particular you need to hit Return to
execute it).  Note that slight tweaks to this may occur in future
versions, though the general scheme is likely to remain the default.

See the README and NEWS files for more.

There are also many bug fixes, notably better protection against race
conditions in interrupts (typically, but not necessarily, those
resulting from exiting child processes), as well as enhancments to
completion functions.

Thank you to the many people who have contributed or otherwise helped.

Please report problems to zsh-workers@zsh.org.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

can we detect the closing of a terminal?

[Ray Andrews]

Gentlemen:

Whenever I open a terminal I have a mechanism for passing to it 
knowledge of the current $PWD of any other open terminals.  It's 
cumbersome but it works.  Problem is that it's a one way thing in that 
when a terminal closes, that information is not passed, so there is 
orphan information.  Is there some 'pre-close()' function for 
terminals?  Sort of a suicide note? Or it might be about the same thing 
to have a function that's called before a shell exits 'zsh-pre-close()' 
, tho of course there can be several layers of shells in one terminal, 
but I guess that one can test for the 'zero' level shell in any given 
terminal.  I'll bet there is one for the shell, but for the terminal 
that might be wishing upon a star.

Re: can we detect the closing of a terminal?

[ZyX]

04.09.2015, 19:03, "Ray Andrews" <rayandrews@eastlink.ca>:
> Gentlemen:
>
> Whenever I open a terminal I have a mechanism for passing to it
> knowledge of the current $PWD of any other open terminals. It's
> cumbersome but it works. Problem is that it's a one way thing in that
> when a terminal closes, that information is not passed, so there is
> orphan information. Is there some 'pre-close()' function for
> terminals? Sort of a suicide note? Or it might be about the same thing
> to have a function that's called before a shell exits 'zsh-pre-close()'
> , tho of course there can be several layers of shells in one terminal,
> but I guess that one can test for the 'zero' level shell in any given
> terminal. I'll bet there is one for the shell, but for the terminal
> that might be wishing upon a star.

You can use `trap` command for this: trap 'command' EXIT (alternative: define TRAPEXIT() function), needs to be defined outside of functions. `man zshbuiltins`, documentation for `trap` built-in also references `zshexit` hook, so it is probably better to use

    function my-zshexit-hook()
    {
        your code here
    }
    zshexit_functions+=( my-zshexit-hook )

. But documentation for this hook says that this hook is “Executed at the point where the main shell is about to exit normally.”: note “normally”. When trying to use this do some tests, maybe you need this trap *and* some trap like TRAPHUP() function, I have not ever needed this.

Re: can we detect the closing of a terminal?

[Kurtis Rader]

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

On Fri, Sep 4, 2015 at 9:02 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> Whenever I open a terminal I have a mechanism for passing to it knowledge
> of the current $PWD of any other open terminals.  It's cumbersome but it
> works.  Problem is that it's a one way thing in that when a terminal
> closes, that information is not passed, so there is orphan information.  Is
> there some 'pre-close()' function for terminals?  Sort of a suicide note?
> Or it might be about the same thing to have a function that's called before
> a shell exits 'zsh-pre-close()' , tho of course there can be several layers
> of shells in one terminal, but I guess that one can test for the 'zero'
> level shell in any given terminal.  I'll bet there is one for the shell,
> but for the terminal that might be wishing upon a star.
>

I'm guessing that by "open a terminal" you mean start an interactive shell.
The distinction is important when you consider cases such as using ssh to
log into another system or starting an xterm that simply displays the
output of a command (possibly a zsh script). Or consider the case where
you're using a program such as "screen" or "tmux" to multiplex access to a
shell. In that case it is normal to create a new "terminal" and connect to
an existing tmux session. Then close that "terminal" while leaving the tmux
session, and thus the interactive shell running within it, still running.

The simplest solution is to create a $HOME/.zlogout script (see "man zsh").
Other solutions such as a TRAPEXIT function or using the trap command to
handle SIGHUP and SIGTERM are also possible. The trap command solution is
the most portable.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: can we detect the closing of a terminal?

[Ray Andrews]

Kurtis, ZyX:


On 09/04/2015 02:37 PM, Kurtis Rader wrote:
>
>> I'm guessing that by "open a terminal" you mean start an interactive shell.
When I fire up an xterm it comes with a zsh shell pre loaded. That's all 
I know. In each one of them you can "echo $TTY" and it will report 
"/dev/pts/2" or some other number than '2'.  I can have a dozen of them 
open, and when I close one I'd like some way of letting the other 
terminals know it. Reason being that each terminal has an associated 
variable 't[number of the terminal]' set to its $PWD and I do stuff 
like: 'cp * $t10' where '$t10' is the current directory on terminal 
'/dev/pts/10' and which does horrible things is terminal #10 has been 
closed so I want some way of killing '$t10' when that happens.

>> The distinction is important when you consider cases such as using ssh to
>> log into another system or starting an xterm that simply displays the
>> output of a command (possibly a zsh script). Or consider the case where
>> you're using a program such as "screen" or "tmux" to multiplex access to a
>> shell. In that case it is normal to create a new "terminal" and connect to
>> an existing tmux session. Then close that "terminal" while leaving the tmux
>> session, and thus the interactive shell running within it, still running.
Yikes, there's more things you mention there than I even know exist ;-)

>> The simplest solution is to create a $HOME/.zlogout script (see "man zsh").
>> Other solutions such as a TRAPEXIT function or using the trap command to
>> handle SIGHUP and SIGTERM are also possible. The trap command solution is
>> the most portable.
>>
Between what you say and ZyX's comments, there's a few things to chew 
on, tho it's mostly way over my head still but I'll give it a dangle and 
thrash.

Re: can we detect the closing of a terminal?

[Kurtis Rader]

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

On Fri, Sep 4, 2015 at 8:07 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 09/04/2015 02:37 PM, Kurtis Rader wrote:
>>
>> I'm guessing that by "open a terminal" you mean start an interactive
>>> shell.
>>>
>> When I fire up an xterm it comes with a zsh shell pre loaded. That's all
> I know. In each one of them you can "echo $TTY" and it will report
> "/dev/pts/2" or some other number than '2'.  I can have a dozen of them
> open, and when I close one I'd like some way of letting the other terminals
> know it. Reason being that each terminal has an associated variable
> 't[number of the terminal]' set to its $PWD and I do stuff like: 'cp *
> $t10' where '$t10' is the current directory on terminal '/dev/pts/10' and
> which does horrible things is terminal #10 has been closed so I want some
> way of killing '$t10' when that happens.


Xterm does not "come with a zsh shell pre loaded". The xterm program by
default runs whatever program is referred to by your SHELL environment
variable. If that environment variable does not exist it will attempt to
use the shell defined for you account. Which, on a UNIX like system, is
typically in your /etc/passwd file or equivalent; I have no idea what the
equivalent is on a MS Windows system. However, you can tell xterm to run
any "shell" you wish. In fact, the program doesn't have to be an
interactive shell. For example, create a file named "xterm_ls" in your home
directory that contains

#!/bin/sh
echo "TTY=$TTY"
/bin/ls
/bin/sleep 10

Make it executable by running "chmod 755 ~/xterm_ls". Then, from an already
open shell, type "xterm ~/xterm_ls". You should see an xterm window appear
that shows the files in your home directory for ten seconds then
disappears. That "terminal" won't have a TTY variable because the TTY
variable is an artifact of a zsh interactive shell. And since that command
did not instantiate an interactive zsh instance there won't be a TTY
environment variable.

Here's another experiment. In an existing "terminal" type the following

SHELL=/bin/sh
xterm

You should get an xterm "terminal" that displays a Bourne shell prompt
rather than your Zsh prompt. After exiting the xterm you just created
you'll want to run

SHELL=/bin/zsh

so that the terminal in which you ran this experiment continues to behave
as expected.

Lastly, you say that

each terminal has an associated variable 't[number of the terminal]' set to
> its $PWD


That is not true. The device path name for stdin and stdout of an
interactive shell depends on both the operating system and how it was
invoked. It might be /dev/pts/2 or /dev/tty or /dev/argle/bargle. You are
using premises that only hold true for the very constrained situation of
interest to yourself today. If you upgrade your operating system tomorrow
(or switch to a different UNIX like OS or a non UNIX like OS) there is a
strong possibility that your scripts will break.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: can we detect the closing of a terminal?

[Ray Andrews]

On 09/04/2015 09:31 PM, Kurtis Rader wrote:
> ...

> Xterm does not "come with a zsh shell pre loaded". The xterm program by
> default runs whatever program is referred to by your SHELL environment
> variable.
I know.  Sorry, I expressed that poorly.  I just mean that as my machine 
is set up, SHELL is in fact zsh, so when I open an xterm I get a new zsh 
for that reason.  It could be otherwise, but isn't.

> ...
> SHELL=/bin/sh
> xterm
>
> You should get an xterm "terminal" that displays a Bourne shell prompt
> rather than your Zsh prompt. After exiting the xterm you just created
> you'll want to run
Yup, I know that too.  I've used it to explore compatibility issues.

> Lastly, you say that
>
> each terminal has an associated variable 't[number of the terminal]' set to
>> its $PWD
> That is not true.
Well, it is true because I make it so.

> The device path name for stdin and stdout of an
> interactive shell depends on both the operating system and how it was
> invoked. It might be /dev/pts/2 or /dev/tty or /dev/argle/bargle. You are
> using premises that only hold true for the very constrained situation of
> interest to yourself today. If you upgrade your operating system tomorrow
> (or switch to a different UNIX like OS or a non UNIX like OS) there is a
> strong possibility that your scripts will break.
Sure.  As you say, I'm constrained in my tiny world doing what works 
locally, and that is satisfactory for my current projects.  One wants as 
much universality as possible of course, and as I learn more, more 
robust code becomes possible.  Meanwhile I crash into gottchas all the 
time, but I guess that's how one learns--you don't know what you don't 
know.  Even worse, you don't know that most of what you do know is wrong.

BTW, it seems I can solve my problem very simply:

c--------- 1   5,  2 2015-09-04_23:48:38 /dev/pts/ptmx
crw--w---- 1 136,  0 2015-09-05_06:49:41 /dev/pts/0
crw--w---- 1 136,  2 2015-09-05_06:49:41 /dev/pts/2
crw--w---- 1 136,  3 2015-09-05_06:49:41 /dev/pts/3
crw--w---- 1 136,  4 2015-09-05_06:49:41 /dev/pts/4
crw--w---- 1 136,  7 2015-09-05_06:49:41 /dev/pts/7
crw--w---- 1 136,  6 2015-09-05_06:49:41 /dev/pts/6
crw--w---- 1 136,  8 2015-09-05_06:49:41 /dev/pts/8
crw--w---- 1 136,  9 2015-09-05_06:49:41 /dev/pts/9
crw--w---- 1 136, 10 2015-09-05_06:49:41 /dev/pts/10
crw--w---- 1 136, 11 2015-09-05_07:08:02 /dev/pts/11
crw--w---- 1 136, 12 2015-09-05_07:08:05 /dev/pts/12
crw--w---- 1 136,  5 2015-09-05_07:09:28 /dev/pts/5
crw--w---- 1 136,  1 2015-09-05_07:17:57 /dev/pts/1

... whenever a terminal closes, it's 'handle' above disappears so if, 
say '$t12' is set but '/dev/pts/12' does not exist, that flags the 
problem. So one of those semi-miraculous string comparisons is in order.

Re: zsh 5.1 released [user]

[Ray Andrews]

On 08/30/2015 12:13 PM, Peter Stephenson wrote:
> Version 5.1 of zsh has been released and is available from
>
> http://www.zsh.org/pub/
>
>
Before installing that, is there a list somewhere of all the bits and 
pieces of zsh scattered around?  I'd like to remove everything because I 
know that some of the bits of zsh on my system are derelict.  If I cut 
it all out then reinstall, I'll know for sure that everything is 
current.  Brute searches for '*zsh* give this:

directories:

/usr/share/doc/zsh-common
/usr/share/doc/zsh
/usr/share/zsh
/usr/local/share/zsh
/usr/local/lib/zsh
/usr/local/lib/zsh/5.0.7-dev-0/zsh
/usr/local/lib/zsh/~5.0.7/zsh
/usr/lib/i386-linux-gnu/zsh
/usr/lib/i386-linux-gnu/zsh/5.0.8/zsh
/etc/zsh

files:

/usr/share/lintian/overrides/zsh-common
/usr/share/lintian/overrides/zsh
/usr/share/man/man1/zshzle.1.gz
/usr/share/man/man1/zshcompsys.1.gz
/usr/share/man/man1/zshroadmap.1.gz
/usr/share/man/man1/zshparam.1.gz
/usr/share/man/man1/zsh.1.gz
/usr/share/man/man1/zshcompwid.1.gz
/usr/share/man/man1/zshzftpsys.1.gz
/usr/share/man/man1/zshoptions.1.gz
/usr/share/man/man1/zshmisc.1.gz
/usr/share/man/man1/zshtcpsys.1.gz
/usr/share/man/man1/zshall.1.gz
/usr/share/man/man1/zshcompctl.1.gz
/usr/share/man/man1/zshbuiltins.1.gz
/usr/share/man/man1/zshcontrib.1.gz
/usr/share/man/man1/zshcalsys.1.gz
/usr/share/man/man1/zshexpn.1.gz
/usr/share/man/man1/zshmodules.1.gz
/usr/share/doc/zsh-common/zsh-development-guide.gz
/usr/share/doc/zsh-common/examples/zshenv
/usr/share/doc/zsh-common/examples/old/jhm.zshrc.gz
/usr/share/doc/zsh-common/examples/zshrc.gz
/usr/share/doc/zsh-common/examples/Misc/bash2zshprompt
/usr/share/doc/zsh-common/examples/Misc/make-zsh-urls.gz
/usr/share/doc/zsh-common/examples/carstenh.zshrc.gz
/usr/share/doc/zsh-common/zsh.texi.gz
/usr/share/bug/zsh-common
/usr/share/bug/zsh
/usr/share/menu/zsh-common
/usr/share/zsh/functions/Chpwd/zsh_directory_name_cdr
/usr/share/zsh/functions/Newuser/zsh-newuser-install
/usr/share/zsh/functions/Completion/Zsh/_add-zsh-hook
/usr/share/zsh/functions/Completion/Zsh/_zsh-mime-handler
/usr/share/zsh/functions/Completion/Cygwin/_mkzsh
/usr/share/zsh/functions/Misc/add-zsh-hook
/usr/share/zsh/functions/MIME/zsh-mime-handler
/usr/share/zsh/functions/MIME/zsh-mime-contexts
/usr/share/zsh/functions/MIME/zsh-mime-setup
/usr/local/bin/zsh-5.0.7-271
/usr/local/bin/zsh-5.0.7-109-g2598010
/usr/local/bin/zsh-5.0.7-242-g0e35489
/usr/local/bin/zsh-5.0.7-319
/usr/local/bin/zsh-5.0.7-125-g167a15a
/usr/local/bin/zsh-5.0.7-165-g2194da1
/usr/local/bin/zsh-5.0.7-217-g39a6e8a
/usr/local/bin/zsh-5.0.7-138-g247f754
/usr/local/bin/zsh-5.0.7-310
/usr/local/bin/zsh-5.0.7-311
/usr/local/bin/zsh-5.0.7-305
/usr/local/bin/zsh-5.0.7-112-g49d6aac
/usr/local/bin/zsh-5.0.7-175-g7e74495
/usr/local/bin/zsh-5.0.7-136-g0a07ffd
/usr/local/bin/zsh-5.0.7-159-g89c692e
/usr/local/bin/zsh-5.0.7-248
/usr/local/bin/zsh-5.0.7-274
/usr/local/bin/zsh-5.0.7-297
/usr/local/bin/zsh-5.0.7-161-g1cd8023
/usr/local/bin/zsh-5.0.7-230-g2b8b1a4
/usr/local/share/man/man1/zshmisc.1
/usr/local/share/man/man1/zshcompsys.1
/usr/local/share/man/man1/zshmodules.1
/usr/local/share/man/man1/zshcontrib.1
/usr/local/share/man/man1/zshall.1
/usr/local/share/man/man1/zshoptions.1
/usr/local/share/man/man1/zshcompwid.1
/usr/local/share/man/man1/zshtcpsys.1
/usr/local/share/man/man1/zsh.1
/usr/local/share/man/man1/zshzle.1
/usr/local/share/man/man1/zshbuiltins.1
/usr/local/share/man/man1/zshcalsys.1
/usr/local/share/man/man1/zshparam.1
/usr/local/share/man/man1/zshcompctl.1
/usr/local/share/man/man1/zshexpn.1
/usr/local/share/man/man1/zshroadmap.1
/usr/local/share/man/man1/zshzftpsys.1
/usr/local/share/zsh/5.0.7-dev-0/functions/zsh_directory_name_cdr
/usr/local/share/zsh/5.0.7-dev-0/functions/zsh-mime-handler
/usr/local/share/zsh/5.0.7-dev-0/functions/zsh-mime-contexts
/usr/local/share/zsh/5.0.7-dev-0/functions/add-zsh-hook
/usr/local/share/zsh/5.0.7-dev-0/functions/zsh-newuser-install
/usr/local/share/zsh/5.0.7-dev-0/functions/_zsh-mime-handler
/usr/local/share/zsh/5.0.7-dev-0/functions/_mkzsh
/usr/local/share/zsh/5.0.7-dev-0/functions/zsh-mime-setup
/usr/local/share/zsh/5.0.7-dev-1/functions/zsh_directory_name_cdr
/usr/local/share/zsh/5.0.7-dev-1/functions/zsh-mime-handler
/usr/local/share/zsh/5.0.7-dev-1/functions/zsh-mime-contexts
/usr/local/share/zsh/5.0.7-dev-1/functions/add-zsh-hook
/usr/local/share/zsh/5.0.7-dev-1/functions/zsh-newuser-install
/usr/local/share/zsh/5.0.7-dev-1/functions/_zsh-mime-handler
/usr/local/share/zsh/5.0.7-dev-1/functions/_mkzsh
/usr/local/share/zsh/5.0.7-dev-1/functions/zsh-mime-setup
/var/cache/apt/archives/zsh_5.0.8-2_i386.deb
/var/cache/apt/archives/zsh_5.0.8-4_i386.deb
/var/cache/apt/archives/zsh-common_5.0.8-2_all.deb
/var/cache/apt/archives/zsh-common_5.0.8-4_all.deb
/var/lib/dpkg/info/zsh-common.preinst
/var/lib/dpkg/info/zsh.prerm
/var/lib/dpkg/info/zsh.postinst
/var/lib/dpkg/info/zsh.preinst
/var/lib/dpkg/info/zsh-common.prerm
/var/lib/dpkg/info/zsh.postrm
/var/lib/dpkg/info/zsh.md5sums
/var/lib/dpkg/info/zsh-common.list
/var/lib/dpkg/info/zsh-common.postrm
/var/lib/dpkg/info/zsh.list
/var/lib/dpkg/info/zsh-common.md5sums
/var/lib/dpkg/info/zsh-common.conffiles
/var/lib/dpkg/info/zsh-common.postinst
/var/lib/dpkg/alternatives/zsh
/var/lib/dpkg/alternatives/rzsh
/home/ray/.zshrc
/bin/zsh5

... some of which is my own junk, of course.

Re: zsh 5.1 released [user]

[Axel Beckert]

Hi,

On Sun, Sep 06, 2015 at 09:43:13AM -0700, Ray Andrews wrote:
> Before installing that, is there a list somewhere of all the bits
> and pieces of zsh scattered around?  I'd like to remove everything
> because I know that some of the bits of zsh on my system are
> derelict.  If I cut it all out then reinstall, I'll know for sure
> that everything is current.  Brute searches for '*zsh* give this:
[...]
> /usr/share/doc/zsh-common
> /usr/share/doc/zsh
> /usr/lib/i386-linux-gnu/zsh
> /usr/lib/i386-linux-gnu/zsh/5.0.8/zsh
> /usr/share/lintian/overrides/zsh-common
> /usr/share/lintian/overrides/zsh
> /usr/share/doc/zsh-common/zsh-development-guide.gz
> /usr/share/doc/zsh-common/examples/zshenv
> /usr/share/doc/zsh-common/examples/old/jhm.zshrc.gz
> /usr/share/doc/zsh-common/examples/zshrc.gz
> /usr/share/doc/zsh-common/examples/Misc/bash2zshprompt
> /usr/share/doc/zsh-common/examples/Misc/make-zsh-urls.gz
> /usr/share/doc/zsh-common/examples/carstenh.zshrc.gz
> /usr/share/doc/zsh-common/zsh.texi.gz
> /usr/share/bug/zsh-common
> /usr/share/bug/zsh
> /usr/share/menu/zsh-common

These directories and files (and some more) are clearly part of a zsh
debian package being installed, namely 5.0.8 as currently only present
in Debian Testing ("stretch"). Please do not delete any of these files
manually as it may wreck the state of dpkg/apt badly.

To get rid the package(s), call "apt purge zsh zsh-common" as root.

> /usr/local/share/zsh
> /usr/local/lib/zsh
> /usr/local/lib/zsh/5.0.7-dev-0/zsh
> /usr/local/lib/zsh/~5.0.7/zsh
> /usr/local/bin/zsh-5.0.7-271
> /usr/local/bin/zsh-5.0.7-109-g2598010
> /usr/local/bin/zsh-5.0.7-242-g0e35489
> /usr/local/bin/zsh-5.0.7-319
> /usr/local/bin/zsh-5.0.7-125-g167a15a
> /usr/local/bin/zsh-5.0.7-165-g2194da1
> /usr/local/bin/zsh-5.0.7-217-g39a6e8a
> /usr/local/bin/zsh-5.0.7-138-g247f754
> /usr/local/bin/zsh-5.0.7-310
> /usr/local/bin/zsh-5.0.7-311
> /usr/local/bin/zsh-5.0.7-305
> /usr/local/bin/zsh-5.0.7-112-g49d6aac
> /usr/local/bin/zsh-5.0.7-175-g7e74495
> /usr/local/bin/zsh-5.0.7-136-g0a07ffd
> /usr/local/bin/zsh-5.0.7-159-g89c692e
> /usr/local/bin/zsh-5.0.7-248
> /usr/local/bin/zsh-5.0.7-274
> /usr/local/bin/zsh-5.0.7-297
> /usr/local/bin/zsh-5.0.7-161-g1cd8023
> /usr/local/bin/zsh-5.0.7-230-g2b8b1a4
> /usr/local/share/man/man1/zshmisc.1
> /usr/local/share/man/man1/zshcompsys.1
> /usr/local/share/man/man1/zshmodules.1
> /usr/local/share/man/man1/zshcontrib.1
> /usr/local/share/man/man1/zshall.1
> /usr/local/share/man/man1/zshoptions.1
> /usr/local/share/man/man1/zshcompwid.1
> /usr/local/share/man/man1/zshtcpsys.1
> /usr/local/share/man/man1/zsh.1
> /usr/local/share/man/man1/zshzle.1
> /usr/local/share/man/man1/zshbuiltins.1
> /usr/local/share/man/man1/zshcalsys.1
> /usr/local/share/man/man1/zshparam.1
> /usr/local/share/man/man1/zshcompctl.1
> /usr/local/share/man/man1/zshexpn.1
> /usr/local/share/man/man1/zshroadmap.1
> /usr/local/share/man/man1/zshzftpsys.1
> /usr/local/share/zsh/5.0.7-dev-0/functions/zsh_directory_name_cdr
> /usr/local/share/zsh/5.0.7-dev-0/functions/zsh-mime-handler
> /usr/local/share/zsh/5.0.7-dev-0/functions/zsh-mime-contexts
> /usr/local/share/zsh/5.0.7-dev-0/functions/add-zsh-hook
> /usr/local/share/zsh/5.0.7-dev-0/functions/zsh-newuser-install
> /usr/local/share/zsh/5.0.7-dev-0/functions/_zsh-mime-handler
> /usr/local/share/zsh/5.0.7-dev-0/functions/_mkzsh
> /usr/local/share/zsh/5.0.7-dev-0/functions/zsh-mime-setup
> /usr/local/share/zsh/5.0.7-dev-1/functions/zsh_directory_name_cdr
> /usr/local/share/zsh/5.0.7-dev-1/functions/zsh-mime-handler
> /usr/local/share/zsh/5.0.7-dev-1/functions/zsh-mime-contexts
> /usr/local/share/zsh/5.0.7-dev-1/functions/add-zsh-hook
> /usr/local/share/zsh/5.0.7-dev-1/functions/zsh-newuser-install
> /usr/local/share/zsh/5.0.7-dev-1/functions/_zsh-mime-handler
> /usr/local/share/zsh/5.0.7-dev-1/functions/_mkzsh
> /usr/local/share/zsh/5.0.7-dev-1/functions/zsh-mime-setup

This (i.e. everything zsh-related under "/usr/local/") is clearly a
locally installed version. If "make uninstalled doesn't clean them up,
you may want to remove them manually

> /var/cache/apt/archives/zsh_5.0.8-2_i386.deb
> /var/cache/apt/archives/zsh_5.0.8-4_i386.deb
> /var/cache/apt/archives/zsh-common_5.0.8-2_all.deb
> /var/cache/apt/archives/zsh-common_5.0.8-4_all.deb

This is just apt's cache of downloaded .deb files. You can clean the
cache with "apt-get clean".

> /var/lib/dpkg/info/zsh-common.preinst
> /var/lib/dpkg/info/zsh.prerm
> /var/lib/dpkg/info/zsh.postinst
> /var/lib/dpkg/info/zsh.preinst
> /var/lib/dpkg/info/zsh-common.prerm
> /var/lib/dpkg/info/zsh.postrm
> /var/lib/dpkg/info/zsh.md5sums
> /var/lib/dpkg/info/zsh-common.list
> /var/lib/dpkg/info/zsh-common.postrm
> /var/lib/dpkg/info/zsh.list
> /var/lib/dpkg/info/zsh-common.md5sums
> /var/lib/dpkg/info/zsh-common.conffiles
> /var/lib/dpkg/info/zsh-common.postinst
> /var/lib/dpkg/alternatives/zsh
> /var/lib/dpkg/alternatives/rzsh

This is part of dpkg's tracking of which packages are installed. If
you delete anything in there manually, you may wreck dpkg's knowledge
of the system badly. They will go away, if you purge the zsh and
zsh-common packages as described above.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: zsh 5.1 released [user]

[Axel Beckert]

Hi,

one more thing:

On Sun, Sep 06, 2015 at 06:55:22PM +0200, Axel Beckert wrote:
> On Sun, Sep 06, 2015 at 09:43:13AM -0700, Ray Andrews wrote:
> > [zsh 5.1]
> > Before installing that, is there a list somewhere of all the bits
> > and pieces of zsh scattered around?  I'd like to remove everything
> > because I know that some of the bits of zsh on my system are
> > derelict.

zsh 5.1 is available in Debian Unstable as 5.1-1 currently. If you
have unstable in your sources.list, you can install it directly via
apt.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: zsh 5.1 released [user]

[Ray Andrews]

On 09/06/2015 09:57 AM, Axel Beckert wrote:
> zsh 5.1 is available in Debian Unstable as 5.1-1 currently. If you 
> have unstable in your sources.list, you can install it directly via 
> apt. Kind regards, Axel 
That sounds like a good idea.  I track testing tho.  Can I force 5.1-1 
as a one-time exception? Or I wonder if I should stick to manual 
install.  I'd think keeping Orthodox as far as Debian is concerned would 
be safer, but ...

Re: zsh 5.1 released [user]

[Axel Beckert]

Hi Ray,

On Sun, Sep 06, 2015 at 10:08:01AM -0700, Ray Andrews wrote:
> Thanks Axel, part of my worries is that some of this is from Debian
> and some via manual install, just as you say. I wonder how much
> overlap there is,

If you haven't passed any specific --prefix or so to your ./configure
call, they should not overlap. At least I never noticed any place
where they do. (./configure by default installs to /usr/local/bin and
/usr/local/etc), debian packages to /usr/bin, /etc and in case of zsh
also /bin.)

> If I uninstall zsh completely, as far as apt is concerned, and then
> install the manual package, will things be done cleanly?

I assume so, yes. (But I also assume it would be safe with the zsh
package from Debian installed. :-)

On Sun, Sep 06, 2015 at 10:13:10AM -0700, Ray Andrews wrote:
> On 09/06/2015 09:57 AM, Axel Beckert wrote:
> > zsh 5.1 is available in Debian Unstable as 5.1-1 currently. If you
> > have unstable in your sources.list, you can install it directly
> > via apt.
>
> That sounds like a good idea.  I track testing tho.  Can I force
> 5.1-1 as a one-time exception?

Yes, but it involves /etc/apt/preferences fiddling to lower unstable's
pin priority. (And you need to add a "unstable" deb-line to your
sources.list of course.)

I use the following in /etc/apt/preferences on my systems running
Testing:

Package: *
Pin: release a=unstable
Pin-Priority: 300

> Or I wonder if I should stick to manual install.

Can't decide that for you, especially because I'm surely biased as
Debian' zsh package maintainer. ;-)

If you uninstall the zsh debian package, make sure,
/usr/local/bin/zsh* is mentioned in your /etc/shells file and
/etc/passwd contains a still installed zsh for your user.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: zsh 5.1 released [user]

[Ray Andrews]

On 09/06/2015 12:37 PM, Axel Beckert wrote:
> Can't decide that for you, especially because I'm surely biased as 
> Debian' zsh package maintainer. ;-) 

Well, I'm inclined to stay close to Mother's skirts in this ;-)

Without fooling around with any files, can I do this:

     aptitude install -t unstable zsh
or
     aptitude update -t unstable zsh


This will probably be the one and only time I'd want to be 'ahead' of 
testing so I'd rather not modify anything ... or would that be the road 
to perdition?

Re: zsh 5.1 released [user]

[Ray Andrews]

On 09/06/2015 12:58 PM, Ray Andrews wrote:
> On 09/06/2015 12:37 PM, Axel Beckert wrote:
>> Can't decide that for you, especially because I'm surely biased as 
>> Debian' zsh package maintainer. ;-) 
>
Just to finalize this thread. Since Axel didn't stop me, and although 
it's not recommended, I went to Debian's 'sid' download page, downloaded 
the three files that seemed relevant

-rw-r--r--  1  771992 2015-09-07_17:15:17 zsh_5.1-1_i386.deb
-rw-r--r--  1 3276150 2015-09-07_17:18:53 zsh-common_5.1-1_all.deb
-rw-r--r--  1 2543930 2015-09-07_17:45:25 zsh-doc_5.1-1_all.deb

... and installed them with dpkg -i. dpkg -c shows me all the files, so 
I could easily then detect orphan stuff, of which there was quite a 
bit.  Then, fiddle with links, and so far so good.

> Well, I'm inclined to stay close to Mother's skirts in this ;-)
>
> Without fooling around with any files, can I do this:
>
>     aptitude install -t unstable zsh
> or
>     aptitude update -t unstable zsh
>
That' doesn't work unless the package lists for 'sid' are installed, and 
since I don't want anything but zsh from there, I didn't do that.

One thing: "$ echo $ZSH_PATCHLEVEL" shows: "debian", which isn't very 
informative.  Is that correct?

BTW I noticed something cool: every file in the packages is either in a 
directory "zsh*" or has "zsh*" in its name, which is quite useful for 
finding stuff. If I'm not mistaken.

Re: zsh 5.1 released [user]

[Ray Andrews]

On 09/06/2015 09:55 AM, Axel Beckert wrote:

Thanks Axel,  part of my worries is that some of this is from Debian and 
some
via manual install, just as you say.  I wonder how much overlap there 
is, and I know not to
break apt, thus my asking.  I'm also fretting about system updates 
tripping over manual updates in some way or other.  If I uninstall zsh 
completely, as far as apt is concerned, and then install the manual 
package, will things be done cleanly?

syntax question

[Ray Andrews]

If I have a variable who's name is partially constructed from the 
contents of another variable:

        eval "t$bb="
        eval "echo \$t$bb"

... the above handles it all fine, but is there a simpler syntax?  I 
understand that most/much of what 'eval' does can be written more elegantly.

syntax question

[Ray Andrews]

${${(z)string}[1]}

... that does what I expect, and it's readable, however I'm curious why 
this does not say the same thing:

${(z)string[1]}

... How can that mean anything different?  It seems to just sorta get to 
the point more quickly and given the " (z) " it seem unintuitive that it 
would only print the first character just as:

${string[1]}

... does.  So in the second line the " (z) " seems to do nothing.  I'd 
expect the first two lines to be semantically the same and the third 
line to be a single character.  Is this explainable?  I know it's a 
nit-pick but I'd like to understand it.

Re: syntax question

[Bart Schaefer]

On Wed, Mar 21, 2018 at 4:15 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> ${${(z)string}[1]}
>
> ${(z)string[1]}
>
> ... How can that mean anything different?

Operator precedence.  The second one is equivalent to
${(z)${string[1]}}, as you observed.

Re: syntax question

[Sebastian Gniazdowski]

On 22 marca 2018 at 02:30:52, Bart Schaefer (schaefer@brasslantern.com) wrote:
> On Wed, Mar 21, 2018 at 4:15 PM, Ray Andrews wrote:
> > ${${(z)string}[1]}
> >
> > ${(z)string[1]}
> >
> > ... How can that mean anything different?
> 
> Operator precedence. The second one is equivalent to
> ${(z)${string[1]}}, as you observed.

Also, better to use (Az), utilizing your underrated patch, because:

% a='abcd'
% echo ${${(z)a}[1]}
a

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org