Note that the `hyperfine` example is actually measuring two nested shells. Unless hyperfine implements a shell-parser of its own, of course.
The -N flag tells hyperfine to not run it in a shell, which means it is not nested.
The Bun Shell
41–50 of 239 posts
Re: The Bun Shell
#42> We've implemented many common commands and features like globbing, environment variables, redirection, piping, and more. Of course on paper that sounds fine. However, something that is missing from here is some assurances of how compatible it actually is with existing shells and coreutils implementations. Is it aiming to be POSIX-compliant/compatible with Bourne shell? I am going to assume that not all GNU extensio…
Scanning to the bottom, it seems like the most likely use is to improve the ergonomics of simple scripts that need to shell out in some cases and also to streamline some of the more mundane package.json scripts, like deleting a directory when cleaning.
Personally, I think it seems like a nice tool blending JavaScript and shell scripting.
Re: The Bun Shell
#43This is like... eval? I thought eval was bad?
Eval with an uncanny valley shell whose commands behave similar to the way you expect, but not necessarily exactly the way you expect.
Re: The Bun Shell
#44Earlier quoted context omitted.
Is this done in zig in the core bun runtime or is it implemented as part of the standard bun lib? How much perf is there? Small commands like cd or ls I'm less interested in. You say you provide your own shell... bsh, zigsh, what?
It’s nearly all in Zig. The parser, lexer, interpreter, process execution and builtin commands are all implemented in Zig. There’s a JS wrapper that extends Promise but JS doesn’t do much else. The performance of the interpreter probably isn’t as good as bash, but the builtin commands should be competitive with GNU coreutils. We have spent a lot of time optimizing our node:fs implementation and this code is implement…
Good to hear you guys made the right decisions. Bun is awesome and the more performance you guys can squeeze with zig, the better. Keep it up! Bang up job already.
Re: The Bun Shell
#45Using Windows for development feels like using Linux for anything but server-side work or Macos for gaming, it'll probably work if you have light requirements and don't use the shell that often, but when I think about the last time I tried it, it almost makes me feel fine paying $500 for a ram upgrade on my next mac
Plenty of people use Windows for development, Linux for development and gaming, and macOS for everything including servers. It’s all about preference.
Re: The Bun Shell
#46I really have a "scientists asked if they could not if they should" feeling about this one. I've seen and tried lots of solutions like that in different languages, but believe now it's a wrong level of abstraction. If you want to provide some crossplatform way to execute ls, providing an "ls()" function is much cleaner. Otherwise you start accumulating issues like: which flags are supported, does it support streaming, what about newlines in file names, how do you deal with non-utf filenames, what happens with colour output, is tty attached, etc. These are new problems which you didn't have when using the native JS filesystem functions. And when they bite you, it's not trivial to see where / why.
None of the examples really look that hard to replace either. The current solutions are not great. But shell-in-js is putting a familiar lipstick on a pig without addressing the real issues.
Also, the clock is ticking for the first "string got interpolated instead of templated" security issue. It's inevitable.
Re: The Bun Shell
#47This is like... eval? I thought eval was bad?
Eval is bad if you're passing it untrusted input. It can be useful in some situations if you know what you're doing.
As for Bun Shell, it runs what you tell it to, just like a shell script or command line in the terminal. It's similar to running file system functions or spawning child processes. It will let you do some damage, sure, but that's your responsibility, "with great power", etc.
Re: The Bun Shell
#48> On a Linux x64 Hetzner Arch Linux machine, it takes about 7ms:
hyperfine --warmup 3 'bash -c "echo hello"' 'sh -c "echo hello"' -N
Next time don't run benchmarks on a garbage host like Hetzner. Their hardware is grossly oversold, their support is abysmal, and they null-route traffic anytime there's a blip.
Re: The Bun Shell
#49I really have a "scientists asked if they could not if they should" feeling about this one. I've seen and tried lots of solutions like that in different languages, but believe now it's a wrong level of abstraction. If you want to provide some crossplatform way to execute ls, providing an "ls()" function is much cleaner. Otherwise you start accumulating issues like: which flags are supported, does it support streaming…
There have been many bad templating languages, but I think JSX is ok. There were many bad markup languages before Markdown, and many bad config file formats before JSON.
None of those are perfect, but they're good enough for many purposes.
Similarly, maybe it's not this one, but I suspect that someone will eventually get this right. I do think it does need to be properly standardized, as CommonMark did for Markdown.
Re: The Bun Shell
#50For something which works across all JS runtimes (Deno, Node) and achieves basically the same, check out the popular JS library Execa[1]. Works like a charm! Another alternative is the ZX shell[2] JS library. Tho haven't tested it. [1]: https://github.com/sindresorhus/execa [2]: https://github.com/google/zx
One thing that surprised me about Node was how slow the default way to shelling out (child_process) could be (probably https://github.com/nodejs/node/issues/14917).
Although according to the linked issue, it has been "fixed", I still ran into a problem during a batch script that was calling imagemagick through a shell for each file in a massive directory; profiling was telling me that starting (not completing) (yes, I was using the async version) the child process increasingly slows, from sub-millisecond for the first few spawns, to eventually hundreds of milliseconds or seconds... Eventually I had to resort to doing only single spawn of a bash script that in turn did all the shelling out.
It seems that the linked execa still relies on child_process and therefore has the same issue. It saddens me to see the only package for node that appears to actually fix this and provide a workaround seems to be https://github.com/TritonDataCenter/node-spawn-async and unmaintained.