[beepbooptheory]

I haven't looked at the code, but I assume this is just taking care of things like pipes, loops, variables, conditionals, etc, and leaving the actual binaries like jq as stubs assumed to be there. Its abstracting the shell, not the programs you run in the shell.

[mananaysiempre]

Sure, but why is that an interesting goal? Historically, bash has had very good backwards compatibility, and it’s unlikely that you need new features anyway.

[hnlmorg]

I have authored a shell in Go and while it doesn’t aim to replace coreutils, it does have a decent number of builtins as part of its application.

So in theory I could build a feature that allows you to ship a self contained executable like you’ve described.

If this is something you’re genuinely interested in and my shell has the right kind of ergonomics for you, then feel free to leave a feature request:

https://github.com/lmorg/murex

[notnmeyer]

you can write bash but run the scripts on systems that may not have bash, is my first thought. packaging “shell” scripts into a scratch container or similar sounds pretty nice for certain use cases.

[adamc]

If that's all you want, is compiling it all into go really better than just having a portable bash?

[adamc]

Right, but wouldn't an app built around creating a container with all the dependencies make more sense?