Live data from Hacker News

The Bun Shell

bun.sh

161–170 of 239 posts

Re: The Bun Shell

#161

In the .net world, we have a namespace called System.IO, that houses cross platform implementations of functions to work with directories, files, searching for files, can't we just have a standard js library in the same spirit, than try to half ass emulate a shell just so someone can run rm - rf. All of this seems extremely unnecessary and a wasted time and energy to solving the wrong problem.

There are so many minor (sometimes major) differences in how even macos(zsh/bash) and linux (bash) works, let alone windows (cmd, powershell)

A layer that abstracts these differences can be very useful for buildng CLI's and just apps with javscsript.

Re: The Bun Shell

#162
post #13

> 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…

I have recently switched to using Nushell as my default shell. They were also writing their own but recently decided instead to begin incorporating github.com/uutils/coreutils (Rust rewrite of GNU coreutils). They target uutils to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.

A commendable effort but to me they are not going far enough. I'd honestly just start over, implement what seems to make sense and only add extra stuff on top if there's a huge demand for it + that demand is well-argumented for.

I get why they don't want to do that and I respect their project a lot. But to me imitating this ancient toolchain is just perpetuating a problem.

Re: The Bun Shell

#163

One of the selling points of this post is that bash is slow to start. But how fast is bun shell? Have anyone compared bash and bun shell start times?

They're not claiming bun is faster to start, only that for use cases where you might otherwise need to shell out hundreds of times bun only needs to start once.

Re: The Bun Shell

#164
post #87

Earlier quoted context omitted.

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 worked on that Node.js issue. If you can share a repro, I'd love to take a look: https://github.com/nodejs/node/issues/new?assignees=&labels=...

That's very kind of you - I tried making a dead-simple repro just now with Node 20, and it seemed to run without the problem. I'll try reproducing it in a bit with my original use case of imagemagick and see if the issue still exists.

Re: The Bun Shell

#165
It's a really good idea and one my company implemented on top of Kotlin Scripting as well. There's a lot of scope for competitors to bash. It's not really a public product (and not open source), but a while ago I uploaded a version and docsite to show some friends:

https://hshell.hydraulic.dev/13.0/

I'm not sure what to do with it, maintaining open source projects can be a lot of work but I doubt there's much of a market for such a tool. Still, Hshell has some neat features I hope to see in other bash competitors:

• Fully battle tested on Windows. The core code is the same as in Conveyor, a commercial product. The APIs abstract Win/UNIX differences like xattrs, permission bits, path delimiters, built in commands etc. The blog post talks about Windows but iirc Bun itself doesn't really work there yet.

• Fairly extensive shell API with commands like mv, cp, wget, find, hash and so on. The semantics deviate from POSIX in some places for convenience, for example, commands are recursive by default so there's no need for a separate "rm -rf" type command. Regular rm will do the right thing when applied to a directory. You can also do things like `sha256("directory")` and it'll recursively hash the directory contents. Operations execute in parallel by default which is a big win on SSDs.

• Run commands like this:

    val result = "foo --bar"()
Running commands has some nice features: you can redirect output to both files, the log and lambda functions, and the type of "result" is flexible. Declare it as List and you get a list of lines, declare it as String and the stdout is all in one.

• Built in progress tracking for all long running operations, complete with a nice animated pulsing Unicode progress bar. You can also track sub-tasks and those get an equally nice rendering (see the Conveyor demo video for an example). There are extensions to collections and streams that let you iterate over them with automatic progress tracking.

• You can ssh to a remote machine and the shell API continues to work. Executing commands runs them remotely. If you use the built-in wget command it will run that download remotely too, but with progress callbacks and other settings propagated from the local script.

• You can define high quality CLIs by annotating top level variables. There are path/directory assertions that show spelling suggestions if they're not found.

• Can easily import any dependency from Maven Central.

And so on. We use it for all our scripting needs internally now and it's a real delight.

Compared to Bun Scripting there are a few downsides:

1. The kotlin compiler is slow, so editing a script it incurs a delay of several seconds (running is fast). JS doesn't have that issue and Bun is especially fast to start. JetBrains are making it faster, and I want to experiment with compiling kotlinc to a native image at some point, but we never got around to it.

2. Bun's automatic shell escaping is really nice! I think we'd have to wait for the equivalent string interpolation feature to ship in Java and then be exposed to Kotlin. It's being worked on at the moment.

3. Obviously, Bun Scripting aims to be a product, whereas hshell is more an internal thing that we're not sure whether to try and grow a userbase for or not. So Bun is more practically useful today. For example the full API docs for hshell are still internal, only the general user guide is public.

4. Editing Kotlin scripts works best in IntelliJ and IntelliJ is an IDE more than an editor. It really wants files to be organized into projects, which doesn't fit the more ad hoc nature of shell scripts. It's a minor irritant, but real.

I think with some more work these problems can be fixed. For now, hopefully hshell's feature set inspires some other people!

Re: The Bun Shell

#166

Earlier quoted context omitted.

Not true - shell does not run on Windows, iPhones etc. Even macOS has issues with those who assume Linux is the only Unix, Apple's bash is very old and does not run many scripts. Unfortunately Javascript does get installed everywhere,

Uh, MacOS has zsh (which has far more features than most other POSIX shells), and even old bash has POSIX compatibility. Your TV/IoT device likely has busybox, as does your router. You install git on windows, it's got a (POSIX) shell. The number of places that lack a shell is tiny. Node/deno/bun are rare, and browsers whilst being more common, still require the device to have some kind of GUI.

Read my comment on macOS please - it explicitly is about dealing with Linux people who write scripts assuming new versions of Bash.

Now if Linux used zsh then your comment is valid.

Bash shell scripts do not necessarily run in zsh.

Most Windows users do not install git. iPhones don't have a shell.

Re: The Bun Shell

#167

Earlier quoted context omitted.

I have recently switched to using Nushell as my default shell. They were also writing their own but recently decided instead to begin incorporating github.com/uutils/coreutils (Rust rewrite of GNU coreutils). They target uutils to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.

Yeah, this is nice but also sad. GNU coreutils is ancient at this point. I know this is probably critical to get user share for nushell and not enough dev resources etc. but I’d wish they were innovating on this front too with simpler and less bloated coreutils, as they are already completely changing the shell paradigm.

It doesn't have to be an either-or proposition Yes?

People are free to experiment with alternative cli utils which are not burdened by backward compatibility while nushell also remains easily adoptable by users who are accustomed to coreutils.

Re: The Bun Shell

#168

I’m increasingly fed up with all shell scripts. Sure shell scripts are great when they’re small. Except then they become not small. But they don’t get rewritten. Piping strings of instructed text between programs is an error prone nightmare. I want full debugger support, strong typing, cross platform support, and libraries not programs. Python isn’t my favorite language. But I’ll take a debugable Python script over b…

Take a look at my comment above about hshell. It has all those things you ask for. Feedback would be useful!

The problem with this space is incentives. HShell exists because it was easy to build given the structure of our main product, and I wanted it for our own internal use. But making it a stable long term product on which anyone can rely requires signing up for long term maintenance, and nobody pays for shells (or do they?). So it's got to be a labor of love.

Re: The Bun Shell

#170
post #77

Looks good, will consider it next time I need to create a complex shell script. For creating cross-platform scripts in package.json I've settled on shx [1]. [1] https://www.npmjs.com/package/shx

Maybe give bsx a try instead? (disclaimer: I'm the maintainer)

    pnpm add --dev bsx

    {
        "scripts": {"cleanup": "bsx rm -rf some-cache"}
    }
https://npm.im/bsx

This would use busybox-w32 on Windows, and regular shell on other platforms. You do have your usual footguns like some *nixes not having some tools installed out of the box, but for the 95% cases this should be fine and it's only 536 kB (vs 1.5M for shx)!

Post reply on HN