From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24274 invoked by alias); 5 Sep 2015 04:31:10 -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: 20514 Received: (qmail 11936 invoked from network); 5 Sep 2015 04:31:08 -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,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QdhGj8sYF0gkG4QxspqL+eTKgMnEbjAwMRLsFx8gBE8=; b=A+gX80lfu4sCa7rgGMCuKf1LyNwAuw+IUgcBL0p+qZAs1inwpx7+BWpq5xWfh+vOX2 YDkuVCPP1crYquCue9yCzHtmacWkAnZjjbwLWEatOxvMJBzkn+md4rTMl8Jvn8mIPivt enkRIpYC8ZVSjGDT5/hFzxLR5D+Xh/iWaKBilBeUK4+aYtXes331LbKfCMCTFDf1M+13 ewMwcOtwWpe3NzB1C1S0bWehgI0tV3VKjeBVasV9RPVl1aOH6lEPhmdYWUi+ZK5VEFhV E3uO7NGbLjDBoGbrx8tWpeRQudJSghzf1VvL1T6wyCm4cmI6/9EaLwlMr0V0i92EURHN J5kA== X-Gm-Message-State: ALoCoQkViXfYELYleD5jlusLfmBfdU5+CMFYlexcTw15v/4i+S/EVDW7vx6Qkxhl5MkOUsrvWYt4 MIME-Version: 1.0 X-Received: by 10.112.156.168 with SMTP id wf8mr6923362lbb.114.1441427465101; Fri, 04 Sep 2015 21:31:05 -0700 (PDT) In-Reply-To: <55EA5C6B.4030608@eastlink.ca> References: <20150830201324.309d36b0@ntlworld.com> <55E9C085.2090301@eastlink.ca> <55EA5C6B.4030608@eastlink.ca> Date: Fri, 4 Sep 2015 21:31:04 -0700 Message-ID: Subject: Re: can we detect the closing of a terminal? From: Kurtis Rader To: Ray Andrews Cc: Zsh Users Content-Type: multipart/alternative; boundary=001a11c33f6e070122051ef87c2e --001a11c33f6e070122051ef87c2e Content-Type: text/plain; charset=UTF-8 On Fri, Sep 4, 2015 at 8:07 PM, Ray Andrews 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 --001a11c33f6e070122051ef87c2e--