$PWD is defaulting to / in split window when using screen with exec

I had a little play around with this. It's a bit tricky to come up with a perfect solution. Possible options are:

1) We check the cwd of the children of the screen process. I can do this, but it's the first child process with a cwd, not necessarily the *current* shell/process in screen. Unless there is some way to determine which process is active under screen which I haven't discovered.

2) The cwd of the terminator process (where it was launched from)

3) The home directory of the user

4) The root folder.

I'm not sure which is most logical and follows the UI principle of "least surprise". I suspect 2 or 3. They are also easier and less invasive to implement.

Opinions?

The 1st solution would be the most logical for me, because it would be closest to terminator usage without screen, and that's probably what most people expect.
At the moment new shells start in / for me which I kind of got used to, but at least trying to start in the same directory would be nice.
For me, using the first child process would be okay, since it has a pretty high "hit rate".

>The 1st solution would be the most logical for me, because it would be closest to terminator usage without screen, and >that's probably what most people expect.

I agree

> At the moment new shells start in / for me which I kind of got used to, but at least trying to start in the same directory would be nice.

At the moment I have my shell cd to ~/ on startup as a workaround, though I think 2 would have the edge over 3 (or 4) -- most of the time 2 would point to the same place (~/) in any case (if launched through a GUI), I would think, but this follows shell convention

> For me, using the first child process would be okay, since it has a pretty high "hit rate".

Most of the time I would have though the first process in going to be the shell, I'm sure there are cases when that won't be the case but won't those be because the user has done something they should know about?

The process tree for screen running multiple "windows" looks like:
screen (cwd not available, causes the root path)
  SCREEN
    /bin/bash (first bash that would be encountered)
    /bin/bash
    /bin/bash
    /bin/bash

There's a psutil library that will descend the children so I can pull the first working cwd, but with screen any of the following three bash could be the active and visible one, and a completely different cwd to the first one. This could be confusing, unless someone has better google-fu and can come up with a way to determine which of screens children is the one with focus.

I had a good dig through the man pages and I couldn't see anything. From inside screen you can get the active window but not from outside (and it indicates it by number which can be changed so doesn't necessarily correspond to order).

I did come up with a workaround using

export PPWD=$PWD; screen

as the command

then sticking

if [ $PPWD ]; then
    cd $PPWD
fi

into my .zshrc file, which then puts me in same directory as the terminator window I spit off from.

Hi Bug subscribers, this is the maintainer (Steve Boddy) of Terminator, who took over from Chris.

In case you were not aware there has been a new release 0.98 of Terminator in the last few days which has many changes, fixes and updates. We also have an ongoing GTK3 port which uses a much more up-to-date libvte.

Even with the ~50 issues closed by that release, and discounting the ~90 outstanding wishlist items, we still have an unwieldy 95 bugs. With the oldest approaching it's 6th birthday and some that haven't seen any updates in nearly 5, it is time for a purge.

My intention is to try and get this list down to a minimum, and for that I need your help.

First I'm going to work through, oldest to newest, setting bugs to Incomplete, pending confirmation that they are still an issue. If after a month there is no feedback, the issue will get closed as Invalid. Here's where you come in. I can't always reproduce, or setting up (i.e. other distros) to even test takes a long time, so I'm going to try crowdsourcing this.

1. Get the latest release. Is it still an issue? If yes, set the confirmed-0.98 tag. For bonus points follow the guide http://gnometerminator.blogspot.com/2015/09/so-you-want-to-try-terminator-gtk3.html and see if the GTK3 branch has same issue, and set the confirmed-gtk3 or notaffected-gtk3 tag.

2. Can you reproduce with an empty/default config file? You can pass "-g temp_config" to do this without affecting your existing config. If you already have Terminator running, you'll need to pass -u as well to disable the DBus.

3. If able to, can you reproduce with another user/guest account?

4. If the issue does not already have clear, precise instructions to reproduce with minimal setup/steps, add them.

5. Put as much info about what you are running.
   * Software/library versions (libvte, gtk, pango, cairo, distro, desktop environment, language)
   * Screens (single or multi)
   * Any unusual / custom packages or configs that might be interacting.

6. If possible attach the config file, unless the issue also happens with an empty one, but mention that.

7. Attach the "-d" debug output from 0.98.

Some common things that cause incidents.

* Strange sizing issues or rapidly shrinking windows - Try turning off Window geometry hints.
* Input (esp. broadcasting duplicate chars etc) problems - Try killing IBus.
* Hand editing of the config file can cause various issues - Due to misunderstanding, incorrect structure or typos.
* Some issues are actually in libvte - This is why testing GTK3 is so important.
* segfaults - Unfortunately these are dying inside the C libraries, and it is usually beyond me to fix those.

Many thanks for your assistance, and hopefully this will get us closer to a bug-free Terminator.

Confirmed in 0.98 and with terminator -ug temp_config

Thia ia on Ubunt u14.04 with the PPA enabled

I am also affected by this problem. Where it gets worse, is that those processes hold locks on temporary files in /tmp and I'm not root on the machine. After a few days, the /tmp filesystem is full, and I can't auto-complete a command in the shell.