Re: idea for new feature (was: Re: sticky-note and zle bindings)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 25,  6:18pm, Robert Knight wrote:
}
} > Here's a slightly different suggestion:  Instead of SHELL_SESSION_ID,
} > how about SHELL_SESSION_FILE ?  The terminal creates a file and puts
} > the path to it in the environment.
} 
} That would work when the shell is running locally, but what if the
} shell is running on another system which the user is accessing via
} ssh?  The terminal emulator doesn't have direct access to the remote
} file system.

Well ... I can think of three cases.

(1) The emulator itself is running remotely and displaying on the local
desktop.  In this case the emulator *does* have access to the "remote"
filesystem, but the desktop manager can't restore such a window, so
there's nothing (special) for us to do.

(2) The emulator is local but the application is "ssh".  This is out of
our purview; ssh could propagate the SHELL_SESSION_* environment and it
would be up to sshd to do the right thing on the remote end as part of
its X11 protocol forwarding or whatever, but whether it does is not for
us to determine.

(3) The emulator is local and the shell is local, but within that shell
the user has started up "ssh" to somewhere.  Our responsibility ends
with making sure that the local shell can record its state, which may
include that it needs to start up an ssh process.  Beyond that point we
are back to case (2).

What other case do you envision where the emulator can usefully be
involved?
 
} Since the shell is the program which is storing the data, I think it
} makes sense for it to be responsible for deciding where to put it,
} rather than the terminal.

The shell DOES determine where to store the data.  The emulator (or the
desktop session) is just creating a semaphore file; think of it the same
way you'd think of .pid file in /var/run, except there's one for each
shell session.  Whether the shell uses it to stash data is secondary,
and up to the shell save-state implementation; I just threw that part
out as a suggestion because it avoids the shell itself needing to have
garbage-session collection code.