Hacker News Reader

Comment by Phlogistique | Hacker News Reader

The README fails to address the elephant in the room, which is that usually shell scripts mainly call external commands; as far as I can tell there is no documentation of which built-ins are supported?

That said, in a similar vein, you could probably create a bundler that takes a shell script and bundles it with busybox to create a static program.

View on HN

Busybox commands often don't support all features used to and differ even substantially if you depend on GNU additions. https://www.busybox.net/about.html

I have been keeping a running list of busybox/toybox deficiencies and differences. There are more than I would have expected.

An alternative is to use crunchgen from NetBSD (also included with some of the later BSDs) which crunches full-featured, source tree versions of multiple utilities in a single, static binary. What busybox refers to as a "multi-call" binary.

It will be larger than busybox of course. I get evertyhing I need in a binary less than 5M.

I also wondered this as well. How is something like "cat file.json | jq '.filename' | grep out.txt" implement into Go?

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.

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.

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.

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

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

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

I assume this is what they are talking about here:

> Standard library: we aim to add first-class support for a variety of frequently used/needed commands as builtins. you no longer need external programs to use them.

That's not going to be an easy task, and would basically entail porting those commands to go.

Disclamer: the elephant in the room has nothing to do with ElePHPant, the PHP mascot.

Reply on news.ycombinator.com