On Sun, Sep 7, 2014 at 5:10 AM, lilydjwg <[email protected]> wrote: > On Sun, Sep 07, 2014 at 08:55:37AM +0100, Paul Jolly wrote: > > [...] > > > > But for now I would be happy for the cwd of the bash instance in the > > current window. My problem is I don't know how to get the PID of the > > current window (indeed if someone can suggest a better approach I'm all > > ears!) > > IIUC, that is client.focus.pid if available. >
Unfortunately, that only gets the PID of the terminal emulator, which doesn't change directory with bash. You need something that digs through the process tree to find the current interactive shell process and grabs its PID. Here's the script I use: https://gist.github.com/Dalrik/20b41ca274a9da47138a Call that script with client.focus.pid as the argument, and it will spawn a new shell in the same cwd in most cases. YMMV. Some notes: - This script will find the "deepest" zsh process under a given PID, which in my case is almost always the currently interactive shell. I have a bunch of alternate environments that I can run as necessary, so it's fairly common for me to have 2 or 3 zsh processes running under a given instance of urxvt. - You'll need to change zsh and urxvt in the script to whatever you use. - This version of the script breaks down if it hits a su'd terminal. I use another one which replaces the pwdx call with a small setuid program which prints the pwd of any process, which allows me to use it on terminals that I've, for example, used `sudo -s` on. I wouldn't recommend doing this unless you understand exactly what the security implications are. If you don't care about tracking down which instance of bash is the one you're interacting with, you could change the checkchildren function to return on the first shell process it finds. In most cases, it's also sufficient to simply increment the PID of the terminal emulator by 1, but there are many cases where that assumption could break down. Hope this helps, Ian
