* zsh 5.1 released [user] @ 2015-08-30 19:13 Peter Stephenson 2015-09-04 16:02 ` can we detect the closing of a terminal? Ray Andrews ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Peter Stephenson @ 2015-08-30 19:13 UTC (permalink / raw) To: Zsh Users [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/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* can we detect the closing of a terminal? 2015-08-30 19:13 zsh 5.1 released [user] Peter Stephenson @ 2015-09-04 16:02 ` Ray Andrews 2015-09-04 17:09 ` ZyX 2015-09-04 21:37 ` Kurtis Rader 2015-09-06 16:43 ` zsh 5.1 released [user] Ray Andrews 2015-09-06 16:50 ` syntax question Ray Andrews 2 siblings, 2 replies; 16+ messages in thread From: Ray Andrews @ 2015-09-04 16:02 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: can we detect the closing of a terminal? 2015-09-04 16:02 ` can we detect the closing of a terminal? Ray Andrews @ 2015-09-04 17:09 ` ZyX 2015-09-04 21:37 ` Kurtis Rader 1 sibling, 0 replies; 16+ messages in thread From: ZyX @ 2015-09-04 17:09 UTC (permalink / raw) To: Ray Andrews, zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: can we detect the closing of a terminal? 2015-09-04 16:02 ` can we detect the closing of a terminal? Ray Andrews 2015-09-04 17:09 ` ZyX @ 2015-09-04 21:37 ` Kurtis Rader 2015-09-05 3:07 ` Ray Andrews 1 sibling, 1 reply; 16+ messages in thread From: Kurtis Rader @ 2015-09-04 21:37 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: can we detect the closing of a terminal? 2015-09-04 21:37 ` Kurtis Rader @ 2015-09-05 3:07 ` Ray Andrews 2015-09-05 4:31 ` Kurtis Rader 0 siblings, 1 reply; 16+ messages in thread From: Ray Andrews @ 2015-09-05 3:07 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: can we detect the closing of a terminal? 2015-09-05 3:07 ` Ray Andrews @ 2015-09-05 4:31 ` Kurtis Rader 2015-09-05 14:27 ` Ray Andrews 0 siblings, 1 reply; 16+ messages in thread From: Kurtis Rader @ 2015-09-05 4:31 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: can we detect the closing of a terminal? 2015-09-05 4:31 ` Kurtis Rader @ 2015-09-05 14:27 ` Ray Andrews 0 siblings, 0 replies; 16+ messages in thread From: Ray Andrews @ 2015-09-05 14:27 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-08-30 19:13 zsh 5.1 released [user] Peter Stephenson 2015-09-04 16:02 ` can we detect the closing of a terminal? Ray Andrews @ 2015-09-06 16:43 ` Ray Andrews 2015-09-06 16:55 ` Axel Beckert 2015-09-06 16:50 ` syntax question Ray Andrews 2 siblings, 1 reply; 16+ messages in thread From: Ray Andrews @ 2015-09-06 16:43 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 16:43 ` zsh 5.1 released [user] Ray Andrews @ 2015-09-06 16:55 ` Axel Beckert 2015-09-06 16:57 ` Axel Beckert 2015-09-06 17:08 ` Ray Andrews 0 siblings, 2 replies; 16+ messages in thread From: Axel Beckert @ 2015-09-06 16:55 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 16:55 ` Axel Beckert @ 2015-09-06 16:57 ` Axel Beckert 2015-09-06 17:13 ` Ray Andrews 2015-09-06 17:08 ` Ray Andrews 1 sibling, 1 reply; 16+ messages in thread From: Axel Beckert @ 2015-09-06 16:57 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 16:57 ` Axel Beckert @ 2015-09-06 17:13 ` Ray Andrews 2015-09-06 19:37 ` Axel Beckert 0 siblings, 1 reply; 16+ messages in thread From: Ray Andrews @ 2015-09-06 17:13 UTC (permalink / raw) To: zsh-users 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 ... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 17:13 ` Ray Andrews @ 2015-09-06 19:37 ` Axel Beckert 2015-09-06 19:58 ` Ray Andrews 0 siblings, 1 reply; 16+ messages in thread From: Axel Beckert @ 2015-09-06 19:37 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 19:37 ` Axel Beckert @ 2015-09-06 19:58 ` Ray Andrews 2015-09-08 1:55 ` Ray Andrews 0 siblings, 1 reply; 16+ messages in thread From: Ray Andrews @ 2015-09-06 19:58 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 19:58 ` Ray Andrews @ 2015-09-08 1:55 ` Ray Andrews 0 siblings, 0 replies; 16+ messages in thread From: Ray Andrews @ 2015-09-08 1:55 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: zsh 5.1 released [user] 2015-09-06 16:55 ` Axel Beckert 2015-09-06 16:57 ` Axel Beckert @ 2015-09-06 17:08 ` Ray Andrews 1 sibling, 0 replies; 16+ messages in thread From: Ray Andrews @ 2015-09-06 17:08 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* syntax question 2015-08-30 19:13 zsh 5.1 released [user] Peter Stephenson 2015-09-04 16:02 ` can we detect the closing of a terminal? Ray Andrews 2015-09-06 16:43 ` zsh 5.1 released [user] Ray Andrews @ 2015-09-06 16:50 ` Ray Andrews 2 siblings, 0 replies; 16+ messages in thread From: Ray Andrews @ 2015-09-06 16:50 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-09-08 2:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-30 19:13 zsh 5.1 released [user] Peter Stephenson 2015-09-04 16:02 ` can we detect the closing of a terminal? Ray Andrews 2015-09-04 17:09 ` ZyX 2015-09-04 21:37 ` Kurtis Rader 2015-09-05 3:07 ` Ray Andrews 2015-09-05 4:31 ` Kurtis Rader 2015-09-05 14:27 ` Ray Andrews 2015-09-06 16:43 ` zsh 5.1 released [user] Ray Andrews 2015-09-06 16:55 ` Axel Beckert 2015-09-06 16:57 ` Axel Beckert 2015-09-06 17:13 ` Ray Andrews 2015-09-06 19:37 ` Axel Beckert 2015-09-06 19:58 ` Ray Andrews 2015-09-08 1:55 ` Ray Andrews 2015-09-06 17:08 ` Ray Andrews 2015-09-06 16:50 ` syntax question Ray Andrews
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).