4 ms·

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 docume

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.

nodesocket 2y ago
I also wondered this as well. How is something like "cat file.json | jq '.filename' | grep out.txt" implement into Go?
- beepbooptheory 2y ago
  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 2y ago
    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.
    - notnmeyer 2y ago
      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 2y ago
        If that's all you want, is compiling it all into go really better than just having a portable bash?
    - hnlmorg 2y ago
      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 https://github.com/lmorg/murex
  - adamc 2y ago
    Right, but wouldn't an app built around creating a container with all the dependencies make more sense?
hezag 2y ago
Disclamer: the elephant in the room has nothing to do with ElePHPant, the PHP mascot.
mkesper 2y ago
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 https://www.busybox.net/about.html
- 1vuio0pswjnm7 2y ago
  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.
zamalek 2y ago
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.
- deleted 2y ago
  [deleted]

nodesocket 2y ago

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

beepbooptheory 2y ago
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 2y ago
  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.
  - notnmeyer 2y ago
    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 2y ago
      If that's all you want, is compiling it all into go really better than just having a portable bash?
  - hnlmorg 2y ago
    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 https://github.com/lmorg/murex
- adamc 2y ago
  Right, but wouldn't an app built around creating a container with all the dependencies make more sense?

hezag 2y ago

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

mkesper 2y ago

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 https://www.busybox.net/about.html

1vuio0pswjnm7 2y ago
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.

zamalek 2y ago

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.

deleted 2y ago
[deleted]