Earlier quoted context omitted.
> Is it aiming to be POSIX-compliant/compatible with Bourne shell? No? It never claimed to be aiming to be POSIX-compliant. It seems like it's just making it easier to write "scripts", or do the equivalent of writing a script, in JS. And if you're NOT using this, then you're also not guaranteed to have a POSIX-compliant shell since you may be on Windows, for example
To be honest, it absolutely should aim to be at least a strictly compatible subset of POSIX, even if it doesn't implement everything. There is really no good reason to XKCD 927 this on purpose, but the mentality regarding this is not written anywhere that I saw. I think the mentality regarding compatibility ought to be documented in more detail. What is considered a "bug"?
The Bun Shell
201–210 of 239 posts
Re: The Bun Shell
#202Earlier quoted context omitted.
An absolutely ludicrous point, shells have some of the fastest startup times of all processes
If you are mindful and optimize your shell config, yea. But common stuff like zsh with oh-my-zsh is known to be rather slow, as in several hundred millisec to start. Depending on you, of course, that might be considered fast. I consider it insanely slow. My shell of preference, "nushell": > Startup Time: 24ms 448µs 147ns Ideally it would launch in < 16ms (1 frame at 60hz), but I can live with this ;-)
Re: The Bun Shell
#203Earlier quoted context omitted.
Why would you need to optimize the config? I'm not talking about running an interactive shell.
You commented on someone mentioning bash being slow to start. So your parent discussed interactive shell, and I assumed you did, since you didn't state otherwise.
Nobody is talking about the startup time of interactive shells.
Re: The Bun Shell
#204Earlier quoted context omitted.
I'd argue the opposite: more computers have an end-user accessible JavaScript engine (a browser) than an end-user accessible shell.
It really depends on how you define "computer".
Re: The Bun Shell
#205Earlier 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.
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
#206Earlier quoted context omitted.
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.
I get where you're coming from, but there's an enormous ecosystem of software written for posix. You wouldn't just be starting over with new standards.. you'd be tossing out a whole world of software that we already have.
I am definitely not advocating for a switch overnight. That would of course be too disruptive and is not a realistic scenario.
In terms of POSIX I'd start with just removing some of the quirkiest command line switches and function arguments. Just remove one and give it 3 months. Monitor feedback. Rinse and repeat.
That's what I would do.
Re: The Bun Shell
#207"JavaScript is the world's most popular scripting language." Perhaps, based on usage. But shell must be the world's most ubiquitous scripting language. Not every computer has a Javascript engine but most have a shell. Many, many computers have no browser, let alone a GUI. Some small form factor computers might have embedded Javascript engine but that's a minority. No browser on the router.
https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/bin/
https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/bin/sh/...
2. FreeBSD
https://svnweb.FreeBSD.org/base/head/bin/
https://svnweb.FreeBSD.org/base/head/bin/sh/TOUR?view=co
3. "OpenBSD" fork of NetBSD
https://cvsweb.openbsd.org/src/bin/
https://cvsweb.openbsd.org/src/bin/sh/Attic/TOUR
4. "DragonflyBSD" fork of FreeBSD
https://gitweb.dragonflybsd.org/dragonfly.git/tree/refs/head...
https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/ref...
OpenBSD defaults to ksh for _login_ shell. But we are discussing _scripting_. Evidence indicates ash is more prevalent as a default scripting shell. It's also the login shell on NetBSD. FreeBSD switched their login shell from tcsh to ash. And even OpenBSD still has ash in their source tree.
Re: The Bun Shell
#208"JavaScript is the world's most popular scripting language." Perhaps, based on usage. But shell must be the world's most ubiquitous scripting language. Not every computer has a Javascript engine but most have a shell. Many, many computers have no browser, let alone a GUI. Some small form factor computers might have embedded Javascript engine but that's a minority. No browser on the router.
https://www.youtube.com/watch?v=fz-_oKWcnjs
ftp -4o'|tar tzf -|grep -c \.sh$' https://nodejs.org/dist/v20.11.0/node-v20.11.0.tar.gz
80
There are 80 shell scripts in the NodeJS tarball. Not to mention all the references to the shell in the documentation. ftp -4o'|tar tzf -|grep \.js$' https://zircon-guest.googlesource.com/third_party/dash/+archive/refs/heads/master.tar.gz
There are no Javascripts in the Dash tarball.NodeJS needs the shell, but the shell does not need NodeJS.
"The shell is not a language."
Whatever it "is" (cf. what it _does_), it's essential.
Re: The Bun Shell
#209"JavaScript is the world's most popular scripting language." Perhaps, based on usage. But shell must be the world's most ubiquitous scripting language. Not every computer has a Javascript engine but most have a shell. Many, many computers have no browser, let alone a GUI. Some small form factor computers might have embedded Javascript engine but that's a minority. No browser on the router.
Re: The Bun Shell
#210Using 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
I had the same thought and had an Intel Mac, but then I tried WSL2 and it just works. Now my daily driver is a PC with specs that I wouldn't be able to afford if it was a Mac.