From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1693 invoked by alias); 5 Sep 2015 14:27:25 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20515 Received: (qmail 18032 invoked from network); 5 Sep 2015 14:27:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Authority-Analysis: v=2.1 cv=T/C1EZ6Q c=1 sm=1 tr=0 a=u7jSFDPde++bqsNIHpLwYw==:117 a=u7jSFDPde++bqsNIHpLwYw==:17 a=IkcTkHD0fZMA:10 a=0GO3-C22p82zRldJ8BAA:9 a=QEXdDO2ut3YA:10 Message-id: <55EAFBC7.2080208@eastlink.ca> Date: Sat, 05 Sep 2015 07:27:19 -0700 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-version: 1.0 To: zsh-users@zsh.org Subject: Re: can we detect the closing of a terminal? References: <20150830201324.309d36b0@ntlworld.com> <55E9C085.2090301@eastlink.ca> <55EA5C6B.4030608@eastlink.ca> In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit 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.