I have implemented the persistent subshell part
NightMachinery opened this issue · comments
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.
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.
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......
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.