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

[Paul Munday]

Launch terminator with screen and exec , eg .terminator -e screen

 then split window, in child windows $PWD is /
parent process reports e.g.

Unable to get cwd for PID 1473: [Errno 13] Permission denied: 'les'

where 1473 is the pid of the screen process

terminator version 0.96

ls -lh /proc/1473/
...
lrwxrwxrwx 1 root root 0 Jan 30 12:36 cwd

(which doesn't seem any different from the ones I can read)

ps auxfw

paul 1376 0.4 0.6 603148 25260 ? Sl 12:35 0:01 gnome-terminal
paul 1380 0.0 0.0 14788 848 ? S 12:35 0:00 \_ gnome-pty-helper
paul 1381 0.0 0.1 40208 4012 pts/3 Ss 12:35 0:00 \_ zsh
paul 1463 0.4 1.0 768088 42512 pts/3 Sl+ 12:36 0:01 \_ /usr/bin/python /usr/bin/terminator -e screen
paul 1472 0.0 0.0 0 0 pts/3 Z+ 12:36 0:00 \_ [/usr/bin/termin] <defunct>
paul 1473 0.0 0.0 26868 1176 pts/5 Ss+ 12:36 0:00 \_ screen
paul 1475 0.0 0.0 27028 1396 ? Ss 12:36 0:00 | \_ SCREEN
paul 1476 0.0 0.1 42584 4604 pts/6 Ss+ 12:36 0:00 | \_ /usr/bin/zsh
paul 1494 0.0 0.1 40212 4024 pts/7 Ss 12:36 0:00 \_ /usr/bin/zsh
paul 1565 0.0 0.0 18272 1216 pts/7 R+ 12:40 0:00 \_ ps auxfw

I get permission denied for the defunct process and the screen processes below it (1472,1473,1475) but not any of the shell instances (1476,1494) or the original terminator process(1463) -- tested using ls -lh /proc/1463/cwd etc

Note sure if it entirely clear form above but 1472 and 1473 are both child processes of 1463

.h
This only happens with exec not If I launch terminator normally and then run screen

See also 1098371 (I don't get a crash with 0.96 but do get this).

[Stephen Boddy (stephen-j-boddy)]

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?

[ajs124 (ajs124)]

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".

[Paul Munday (paulm-4)]

>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?

[Stephen Boddy (stephen-j-boddy)]

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.

[Paul Munday (paulm-4)]

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.

[Stephen Boddy (stephen-j-boddy)]

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.

[Paul Munday (paulm-4)]

Confirmed in 0.98 and with terminator -ug temp_config

Thia ia on Ubunt u14.04 with the PPA enabled

[Xavier Hardy (xavier-hardy)]

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.