I have implemented the persistent subshell part

[NightMachinery]

Just have one sub-shell and send commands to it instead of forking a new one for each command. That would allow persistent shell variables.

I have created a project that does this: https://github.com/NightMachinary/brish
It's pretty much as easy as this:

from brish import z, zp

z('echo {python_command_here_that_gets_quoted_automatically(...)}')
zp("echo zp is like z but prints the result's stdout in addition to returing a CmdResult")
zp("echo :e disables quoting {'$test1'} {'$test2':e}")

They accept fork=True to fork, but by default don't, so variables persist.

[NightMachinery]

brish doesn't play well with. interactive commands though, or any command that wants to access stdin/stdout of the terminal (e.g., using cat to get input from the user). This is because brish uses stdin and stdout of the shell process to communicate commands to it and get the results from it. I am thinking of using unix sockets for this instead to allow the shell to inherit the original process's stdin and stdout, but haven't implemented that yet.

[terrycojones]

Hi @NightMachinary - thanks for all this. I'm sorry for my very slow reaction, I only just saw your message! I wonder if brish could invoke the shell so it is using different file descriptors? I used to know more about that stuff, 30+ years ago......

[NightMachinery]

I don't understand the question. brish launches one instance of the shell server as a new process, and communicates with it using that process's file descriptors (stdin and stdout). The shell server runs the command using eval and returns their results in a simple format that brish parses. There is also no async support.