env variable inherited by every shell of a tab or other way to recognize to which tab a shell belong

I *think* I understand what you are asking for. The answer would be to use the remotinator commands to get either a UUID or a title for a terminals parent tab.

However... I just tested the remotinator tab commands and they are currently not working properly.
1. The dbus function calls are not properly aligned causing an exception. (GTK2 only, easy 2 line fix - already in my local copy.)
2. Getting the title does not work for the first tab. (Seems to be a bug in the old GTK libraries, as it is OK in the GTK3 version of Terminator.)
3. All tabs return the same UUID, which is for the tab widget as a whole, not the individual tab itself. (Is it enough to add a tab index num on the end of the uuid which is an easy one liner but could cause issues elsewhere? Add a new get_tab_number call which is fairly simple and cleaner? Or do we start creating/managing per tab UUID's which is the most difficult?)

Note that there would be some restrictions on this working, mainly that:
1. it will only work with the current user on the local system, as it relies on connecting to the DBUS with a known TERMINATOR_UUID to determine the tab. If you are accessing other users/systems, this will not work.
2. it will only work for the first instance of Terminator started, as this is the only one that responds to DBUS commands.
3. It will probably only work effectively using layouts, where the UUID (and potentially title) are persistent. New tabs have default titles and random UUID's (see above caveats on using this), so choosing which common environment variable to use would be a problem.

Thanks Stephen Boddy, that solved my question.

sorry,

I accidentally hit something while I was writing my answer, sorry for that two posts... here is my proper answer:

what I am trying to do is to replicate my current working setup based on screen and tmux, in every tab of screen I have a tmux session which is initialized with a bunch of env variables that come from a certain config file that I usually put in the folder of the associated project.

I would like to replace this screen+tmux setup with terminator, to enjoy its very nice features. In order for doing that I would like to be able to associate some unique id of the tab a process is opened into with a configuration file, so that I can read the configuration file and restore the proper variables for the project I am working in for that particular tab.

basically none of the issues you have cited are a problem for me: I am already using the gtk3 version since it works more nicely with some programs, I will be using this from a single user, with a single terminator instance, of course the one with the dbus server. The randomness of the uuids will not be a problem, since I will be invoking an explicit shell script when I want to associate a tab with a project, and that command I think will create a file with name = tab uuid, contnet = the path to the config file i want associated with that tab.

I tried esecuting remotinator get_tab, this is what I got:

Traceback (most recent call last):
  File "/usr/local/bin/remotinator", line 82, in <module>
    func(uuid, options)
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/ipc.py", line 179, in _exec
    func(proxy, *args, **argd)
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/ipc.py", line 230, in get_tab
    print session.get_tab(uuid)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 654, in _message_cb
    (candidate_method, parent_method) = _method_lookup(self, method_name, interface_name)
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 248, in _method_lookup
    raise UnknownMethodException('%s is not a valid method' % method_name)
UnknownMethodException: org.freedesktop.DBus.Error.UnknownMethod: Unknown method: get_tab is not a valid method

thank you for your time helping me figure out how to implement this
regards

Strange. That looks like the gtk2/trunk error I had to fix. When you call remotinator, is it the script from the gtk3 version, or are you possibly picking up an older gtk2 version? Use the --version flag. If it is 0.98 then that is the (incorrect) gtk2 one. If it is 0.97 then that is the (correct) gtk3 one. Ignore the fact that the gtk3 version is "older", it just hasn't been updated since the branching that happened pre-0.98.

Put simply the remotinator script used must be the one that came in the archive/checkout, so you may have to use an absolute path. If you rely on the PATH env var, there's a good chance you'll be hitting a distro packaged gtk2 version of that script. i.e. use something more like:
/home/<user>/development/terminator/gtk3/remotinator get_tab
instead of:
remotinator get_tab

Possibly you didn't fully understand issue 3. All terminals under any tab in a window will report the same uuid. The uuid relates to the notebook widget that contains a number of tabs, not the tabs themselves. So an example of one of the above suggestions is to change terminatorlib/ipc.py, line 161 from:
return root_widget.uuid.urn
to something like:
return '%s+%d' % (root_widget.uuid.urn, root_widget.page_num(terminal))
which would give something like:
urn:uuid:e17b11f6-63ee-44f7-94e2-b784f13da133+0
where the "+n" at the end is the page number/index of the tab the terminal belongs under. Play with it, you'll get the idea.

hi, you were right about remotinator version. Sadly I got some problems even using the gtk3 version:

[root@avanguardia64] ~paul: /software/terminator/gtk3-xx/remotinator get_tab
/software/terminator/gtk3-xx/terminatorlib/util.py:20: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, Gdk
Traceback (most recent call last):
  File "/software/terminator/gtk3-xx/remotinator", line 82, in <module>
    func(uuid, options)
  File "/software/terminator/gtk3-xx/terminatorlib/ipc.py", line 178, in _exec
    proxy = bus.get_object(BUS_NAME, BUS_PATH)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name net.tenshu.Terminator20x1a6021154d881c was not provided by any .service files

[root@avanguardia64] ~paul: /software/terminator/gtk3-xx/remotinator --version
/software/terminator/gtk3-xx/terminatorlib/util.py:20: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, Gdk
remotinator 0.97

That looks like it is unable to connect to the Terminator DBus (though I will admit that a better error message would be useful.)

A couple of things to check:
1. You have GTK3 Terminator started before running the gtk3 remotinator command.
2. In the Preferences -> Global -> Behaviour area ensure that DBus Server is checked. (This requires a restart of Terminator)

This is the only thing I can think of that would cause the error above.

Hello, I have managed to resolve my problems with remotinator, now it is working fine under terminator/gtk3.
First thing I noticed: there is no "default" tab. If I call get_tab or get_tab_title when there is not tab, nothing (or null) is returned. If I create a tab, each of the tabs (the previous one that wasn't a tab, and the new one) have a uuid and a title. If I destroy one of the tabs, the other looses uuid and title.
this can be a problem for what I wanted to do, haven't tried to set a title myself when there are no tabs and see if it persist across those steps, will do tomorrow. I also forgot to check if those ids where different between tabs.
If none of this works, and by that I mean give me something reliable to recognize in which tab is located each process, maybe I can use the windows instead of the tabs to achieve the same goal... the windows should (haven't checked that either) have unique window ids.
Of course your idea to create unique tabs ids adding the tab number to the end could solve my problem, it could also create potentially other issues like you pointed out, so it would be best to use what already is available...
regards

Yeah, the original code is a bit too clever for it's own good, deleting the notebook widget (the tabs) when only one "tab" of terminals is open, and making the terminal/splitters the child of the main window instead. As a result the last tab title is not tracked on closing the penultimate tab, and then opening a new one.

Someone previously had done an implementation of was to always have a notebook widget, and just hide the tab bar when only one is being used. I wasn't convinced at the time, and the code was never merged as the author never revisited it. It may be worth reconsidering this. Of course, even this would only remember the last tab title - it wouldn't remember the title of other closed tabs.
(You can see the work that person did here: https://code.launchpad.net/~iq-0/terminator/terminator/+merge/191196 )

Yup, windows are definitely unique.

Hi, I tried a few times but I wasn't able to make remotinator work under gtk3 again, maybe the first time (when I thought it was working) I was using it under gtk2 without noticing due to launching an instance of terminator gtk3 from an instance of terminator gtk2.
Sadly this means my plan to take over the wo.. to do fancy things with the shell needs to be procrastinated to a time I can dedicate more then a few hours to the matter.
Not completely in subject but you think terminator gtk3 will ever be the default version of terminator packaged with newer linux distributions?