ASH_SESSION_ID set but __ash_* functions not defined

[sjjf]

I run ash on my Ubuntu desktop, with a large collection of gnome-terminal sessions running across multiple windows, all started from a single terminal. ash works nicely in the first session, but later sessions somehow inherit the ASH_SESSION_ID value in their environment but not the function definitions - simply checking for the session id and bailing doesn't result in a usable environment.

I have a fix for this issue, and I'll submit a pull request for it - I'm not sure if there's a better approach, though. Looking at the other open issue at the moment (#3) it's possible that this is something that happens more broadly than just my environment . . .

[barabo]

After applying your proposed fix, does the session ID get updated?

[sjjf]

The session id stays the same until I log out (thereby killing the initial terminal session, with the original bash process that set up and exported the ASH_SESSION_ID value).

I looked into this more deeply and I think it's caused by the fact that the ASH_* env variables are exported, but the functions aren't - child terminal sessions see the environment set up for ash but they don't have the core functions defined, so they fail miserably. Either exporting the functions, or ensuring that all the environment setup is limited to a single process should make it work (I.e. don't export /anything/, or export everything ash needs to work). My proposed fix just works around the issue.

I guess what approach you take depends on how you want to define a "session" - does that mean a single bash process, a bash process and all its children, a single login session (which might require a different mechanism for exporting the session information?), or something else? I can see either a single process or all its children both being entirely valid models, but it's not something I think matters all /that/ much, as long as the whole implementation is consistent.

[barabo]

A fix was merged. The net result of this is that when a new terminal is launched from an existing one (where the ASH_SESSION_ID has been exported), the launched terminals will share the same session ID. This stretches the definition of what a session should be (in my mind), but if it's a useful feature that's fine.