Open quark-zju opened 3 years ago
I think wzsh could be used for this, and maybe without a huge effort; the loop constructs are probably the most difficult part, and those shouldn't be all that hard.
In theory, you'd target the shell_vm
crate for the library interface; you'd provide a ShellHost
impl for spawn_command
to control what/how things are spawned, and in there you could decide how to handle the "spawned" command; the interface is intended to allow for immediately processing the args/environment, or spawning a thread or a child process with some captured information.
Some of the shell builtins live in the top level wzsh command crate (https://github.com/wez/wzsh/tree/master/src/builtins) rather than shell_vm, so it will probably make sense to move those around; perhaps it is worth making a wzsh-embed
(or insert a better name) crate that is a slightly augmented version of shell_vm
with some more general useful helper functions included.
It seems another difficult area is parsing. Some tests use syntax like $((x+1))
, or [ a = b ]
. Support seems missing. I found the lexer and parser are hand-written. Have you considered tools like lalrpop
?
I found 2 Rust projects:
They seem quite complete for the .t
use-case: Namely, it has $((x+1))
, heredoc support commonly missing elsewhere. And it has abstractions to customize process execution. I will probably try to build something on top of them. Thanks anyway!
The
.t
tests used by Mercurial is basically a shell script with fancy input output checks. It was extracted to https://pypi.org/project/cram/.While it works reasonably fine, there are some issues:
$PATH
.I have been thinking about a shell interpreter that accepts a subset of the shell language for the
.t
case, and avoids spawning processes. It needs a shell-ish features but with one extra feature:cat
will be redirected to a builtin Rust functionfn cat(in: impl Read, out: impl Write, err: impl Write) -> ExitCode
.That would allow us to explicitly control dependencies, and potentially reduce the Python startup overhead (by pre-import things).
Now the question is, do you think
wzsh
can be purposed in this direction? I think the questions are around:for
,while
used in.t
tests.