Global environment variables from outside are not keepen inside.

[pi-dev500]

I use a lot X11 Forwarding on my raspberry pi, and when I try to start graphical apps from your embedded terminal emulator, It says that it does not have any access to DISPLAY. That's normal, DISPLAY is specific to that ssh session there. That's just an example to show that if I do export CONST="This is the value", and then I start a textual app with your terminal inside in the same session to print the value of "CONST":

$ echo ${CONST}

$

If this can be solved quickly, this would help me a lot, because I need that to work in order to have pi-apps manage-daemon working inside your widget. I'm planning on making a yad wrapper for textual, but I don't have the time yet. Thank you for this amazing project !

[mitosch]

Thank you for the report and the feedback.

I understand the problem so far, that there are no environment variables set in the embedded session. Is that correct?

Maybe the solution is simple and you just need to set the environment variable inside the embedded terminal by sending a command, but it is just a guess.

If it goes deeper to X11 forwarding I don't know the solution. Do you have any idea how to solve it?

A pull request would be appreciated.

Thanks in advance.

[pi-dev500]

The problem is exactly that: the environment variables are not set in the terminal. I think that to solve that, we should take the global environment variables from the terminal wich runs the application using env=dict(os.environ), then overiding it with a for loop before starting the command. env.

[pi-dev500]

In my case, with x11 forwarding, it is just the $DISPLAY environment variable which is not set. This means that the programs that you launch from inside your embeded terminal are trying to connect to the default display, the :0 x server on localhost, which obviously does not exists. A possible display name for x11 over ssh is 192.168.1.72:0 for exemple. (<server ip>:<display number>)

[paulrobello]

Subshells unless explicitly told not to, usually inherit all env vars from parent shell.
This should be a quick win for more functionality.
Maybe have the option to opt out of parent env vars as well.