The Bun Shell
bun.sh
bun.sh
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 extensions are available; probably something like mkdir -p is, but I'd be surprised if GNU find with all of its odds and ends are there. This might be good enough, but this is a bit light on the details I think. What happens when the system has GNU coreutils? If more builtin commands are added in the future, will they magically change into the Bun implementation instead of the GNU coreutils implementation unexpectedly? I'm sure it is/will be documented...
Also, it's probably obvious but you likely would not want to surprise-replace a Bourne-compatible shell like ZShell with this in most contexts. This only makes sense in the JS ecosystem because there is already a location where you have to write commands that are going to be compatible with all of these shells anyways, so just standardizing on some more-useful subset of Bourne-compatible shell is mostly an upgrade, since that'll be a lot more uniform and your new subset is still going to be nearly 100% compatible with anything that worked across most platforms before, except it will work across all of the platforms as-intended. (And having the nifty ability to use it inside of JS scripts in an ergonomic way is a plus too, although plenty of JS libraries do similar things, so that's not too new.)
Personally, I think it seems like a nice tool blending JavaScript and shell scripting.
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.
Mutex does this by having these utilities named slightly different to their POSIX counterparts. So you can use all of the existing CLI tools completely but additionally have a bunch of new stuff too.
Far too many alt shells these days try to replace coreutils and that just creates friction in my opinion.
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 don't feel as though anyone is forcing me to do anything though, that's definitely not the tone I intended to convey.
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.
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
I feel the best way to handle this is for $ to require all non-bultin calls to be explicit and try to replicate utilities as builtins as much as possible
> Also, it's probably obvious but you likely would not want to surprise-replace a Bourne-compatible shell like ZShell with this in most contexts. This only makes sense in the JS ecosystem
The sheer size of the JS runtime is enough argument to not use it in a non-JS project. Not a jab at JS or Bun, python/ruby/etc can't compete with shell script runtime size either
They are busy building useful stuff whilst others pontificate about what they should/shouldn’t build
[0]: https://github.com/google/zx
You decide your own definitions, but that's very different from "Gmail by Google" or even "Go by Google" in my book. Note how the main author has "Ex-Google" in their bio, too.
If someone does want to retain copyright, there’s another process for getting approval.
Small nitpick but on Arch, /bin/sh is a symlink to bash so it's measuring the same thing.
On many systems like Debian, /bin/sh is dash instead (though default interactive shell remains bash) which is actually a few times faster, for start up and in general.
Unlike zx/execa, we have our own shell instead of relying on a system-installed one.
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 implemented similarly. We expect most scripts to be simple one-liners since you can use JS for anything more complicated.
import { $ as sh } from "bun";
Another alternative is the ZX shell[2] JS library. Tho haven't tested it.
Which bun also acknowledges here:
https://github.com/oven-sh/bun/blob/main/docs/runtime/shell....
I suppose one significant difference is that bun reimplements shell built-ins. I believe that zx simply executes bash or powershell and fails if neither is available.
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.
functionName`param`
So if you think about it template strings are like a tagged template who's function just calls .toString() and concatenates each argument it is given. There are some really nice safe sql libraries that use this for constructing queries. They are useful basically anywhere you might want string interpolation and a bit of type safety, or special handling of different types.
Lit Element is also a very clever usage of tagged templates.
(and everybody with a HERE doc implementation that doesn't have that yet should absolutely implement it, people who can't stand perl deserve access to that feature too ;)
perl has block based lexical scoping and compile time variable name checking.
python and PHP both have neither, which continues to make me sad because I actually -do- believe that explicit is often better than implicit.
perl has dynamic scoping (including for variables inside async functions using the newer 'dynamically' keyword rather than the classic 'local'), which I don't think PHP does at all and python context managers are -slowly- approaching the same level of features as.
perl gives you access to solid async/await support, a defer keyword, more powerful/flexible OO than PHP or python, and a database/ORM stack that really only sqlalchemy is a meaningful competitor to of those I've used in other dynamic languages.
Sure, if you're writing perl like it's still 2004, it -does- kinda suck. But so did PHP 4.
The "why not use" argument is probably better made with respect to modern javascript (I'm really enjoying bun when I have the choice and I can live with node when I don't), since "let" and "use strict;" give you -close- to the same level of variable scoping, plus usable lambdas (though the dynamic scoping still sucks, hence things like React context being ... well, like they are), and the modern JS JITs smoke most things performance-wise.
Oh, and a bunch of people who used perl for systems/sysadmin type stuff have switched to go, which also makes complete sense - but using python after using perl -properly- has a significant tendency to invoke "but where's the other half of the language?" type feelings, and I think that's only somewhat unfair.
(python is still awesome in its own right, and PHP these days is at least tolerable (and I continue to be amazingly impressed by the things people -write- in PHP), but "worse php" is just a -silly- thing to say)
NB: If anybody wants specific examples, please feel free to ask, but this comment already got long enough, I think.
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 bash hell 100% of the time.
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.
Pros:
* LSP
* faster compile times than the node startup time
* cross-platform
* strong types
* great std + many libs available
* not bash script
* fits easily in CI
* not bash script :-)Is it very inefficient? Yes it is. And npmjs.com will block your IP if you do too many downloads in on day.
Actually is says 86m a week here: https://www.npmjs.com/package/rimraf
rm -r -fo my-folder-name
Today if I want to reliably automate some scripting I do NOT use shell scripting because it makes a bunch of implicit dependencies on existing system.
Instead I write these utility scripts in either JavaScript or PHP depending on the project and this seems to give JavaScript a slightly nicer consistent interface to perform basic functionality, built directly into the runtime.
A typical problem of this is when having to run a script (say rm -rf dist) in windows and mac systems not the command itself
A layer that abstracts these differences can be very useful for buildng CLI's and just apps with javscsript.
It's solving a -different- problem, and it may not be a problem that you personally have, but as I think the various excited comments rather demonstrate, it absolutely -is- a problem plenty of people -do- have and it's a really nice thing to have available for us.
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 ;-)
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.
If nothing else it'll make development-side package.json commands easier and nicer, which is still IMO a net win.
My main concern is that when things don't work as expected, the added layer of complexity will make it harder to figure out why. Hopefully there aren't too many rough edges.
For instance, Haven't tried it out but could someone who has tried this on Linux tell me what happens when I type Ctrl-Z in Bun when it is in the middle of running a command or pipeline ? Do I get a Bun shell prompt?
pnpm add --dev bsx
{
"scripts": {"cleanup": "bsx rm -rf some-cache"}
}
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)!
I'm wondering if it's picked up any ideas from oil shell [1].
E.g. How do you profile Rust programs on Windows in RustRover/Clion? How do you run Coz on Windows? Basically WSL or a full VM.
That's because unlike other shells where piping just passes through binary stream, Powershell is based around the concept of piping streams of .NET objects so it will try to parse output of one native command into a list of .NET strings, one for each line, and then print them out to input of another command. Not only making it extremely slow but also changing new lines \n to \r\n and maybe other special characters.
I just use vscode and native toolchains.
I don't even use WSL2 but I have basically identical experience as I do on my Linux desktop or my macOS desktop.
Windows + Mac is the slower of the trinity but not by a huge margin.
With Windows you really must disable the Windows Defender stuff for your dev folder or performance will tank as it scans build artifacts for viruses all of the time.
I successfully developed a large number of cross-os apps and currently are working on a game.
I think the OS at this point is not relevant.
I mostly game in Linux these days, so the Windows install is used less and less.
But that also doesn't make much sense given that this is about non interactive scripts.
To be honest it's kind of crazy that for all the work that's gone into nodejs, it either doesn't have, or people don't know about, basic functionality that these examples are running a shell for.
Is that fairly new? I thought the default shell was bash.
The manual page for mksh also mentions Android in the introduction for those who do not understand the role.
I'm sure there's a use-case somewhere, but if I'm using js I will just use a regex instead of reaching for grep. If I want the shell I'll use the shell.
> # WARNING: No stability is guaranteed on the experimental Windows builds
Now your scripts simply will randomly break on Windows and you won't even know why!
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"()
• 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!
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.
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.
YAML is full of pitfalls. I think the brackets/braces and quotes are worth giving up a small amount readability to eliminate the ambiguity.
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...
A bad templating language would be worlds better than JSX.... "JSX may remind you of a template language, but it comes with the full power of JavaScript".
JSX is javascript.
This is the very sin that PHP spent its early years getting thrown under the bus for.
IF you build a rich react app, and then figure out later that you need a bunch of static, partial static late hydration pages your going to be running node/bun in production to generate those because its not like you can hand JSX to another, performant, language.
And yes im aware of things like packed. The problem is JSX templates, to a large degree, are not compatible.
Code in templates was bad when PHP did it, when Perl did it, it's bad now.
Not so fast. Did you uppercase the first letter of the file and tested on macos and windows? It will fail on linux. Did you create a file called con.js and test it on non-windows machine? It will fail on windows. Did you rely on sub-second precision timestamps? It will fail on some windows machines.
This is a leaky abstraction. People will run into problems.
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.
Definition of computer: "a device, usually electronic, that processes data according to a set of instructions."
Maybe it's pedantic, but you're simply not counting trillions of real computers in the world doing valuable work without any kind of user interface, even IoT devices that are connected to the internet. I have dozens of home automation "computers" that have no such end-user accessible shell, but I can definitely ping their IP address and control them in various ways - and I create the firmware for devices (ESP32 primarily), so I can assure you they are the full definition of "a computer" and that they have no shell, do not run javascript, and have no browser.
And yet those embedded devices can be forced to run a version of Javascript.
>"I'd argue the opposite: more computers have an end-user accessible JavaScript engine (a browser) than an end-user accessible shell."
So let's use a specific goalpost and frame "a computer" as a desktop personal computer.
Today, there are no mainstream personal computers sold that don't come with both a user accessible shell and a web browser. Even Chromebooks have a shell. Just because a user doesn't have a clue how to use it doesn't mean it's not there.
Oh, did you mean to include phones in this pointless internet argument? Because that's an entirely different goalpost, and if you want to include phones then you should also include routers, IoT and embedded devices as "computers", says me.
To me it seems they are just about as irrelevant to the topic at hand as anything could possibly be, but you are getting very hung up on including them in the debate for reasons that elude me.
Here's my argument in simpler terms that you may understand:
Across all objects in the known universe that have an end-user accessible either shell or javascript language interpreter, I claim there are more objects that have the javascript interpreter.
Do you now see how your claims about embedded IOT devices with no shells or js engines being "computers" that could maybe someday run various programs is completely off topic?
Yes, there really is.
>Here's my argument in simpler terms that you may understand:
No need to be condescending about a disagreement in semantics.
>Across all objects in the known universe that have an end-user accessible either shell or javascript language interpreter, I claim there are more objects that have the javascript interpreter.
You'd be wrong. And you're being purposely vague. You haven't proven anything towards your assumption.
But lines need to be drawn. Is a phone a computer? If a phone is a computer, then so must an IoT device be a computer, or a managed network switch, and then your argument is falling apart.
I'm setting some goalposts since you don't seem to understand that goalposts are required to win a pointless internet argument.
I'm saying that if you include phones then you must also include other types of devices like routers and networking equipment and many other "objects in the known universe", and then there are many more devices that have a shell that do not have a web browser, and then you lose.
So set some definite goalposts if you want to continue this pointless conversation.
I gave the iOS example. 2 Billion devices with a browser but no shell. You have given no examples, other than devices which by your own admission have no shell or js engine, and are accordingly out of scope for this argument.
> If a phone is a computer, then so must an IoT device be a computer, or a managed network switch, and then your argument is falling apart.
I don't care what you include in the universe of "computers", all I care about is whether a given thing has an end-user accessible shell or js engine. If you think my argument is falling apart due to the existence of things which have absolutely no relation to it, I don't know what to tell you.
I'm trying, but I really don't think I can be any more clear with you. Let's revisit my initial request of you:
> Can you give an example of a device that has an end-user accessible shell, but not an end-user accessible browser?
To date all you've mentioned are devices which have no shell or js engine. I don't understand how you think you're being relevant.
And the goal posts have been immobile and obvious to everyone but you from the very beginning: count the devices where the user can access a browser, count the devices where the user can access a shell. Which number is bigger?
I've given plenty of examples. But you are unwilling to define
>I don't care what you include in the universe of "computers", all I care about is winning pointless internet arguments.
FTFY
You ran to the 'iPhone' example as if the reality distortion field would block me, but it doesn't prove anything. There are billions of servers, network switches, supercomputer installations that are all definitely computers with a shell that don't have a web browser in any way shape or form. Every computer in the entire "cloud" has a shell but not necessarily a web browser, and usually don't have one. Every container running on those servers is essentially a server with a shell. It's a deep rabbit hole if you want to go down. Practically every house with an iphone has at least 1 network router if not more, most have a shell but no browser. The list goes on and on and on. But sure, die on that iPhone hill like so many others before you.
Now that that's out of the way, we can begin to evaluate it on truth.
> There are billions of servers, network switches, supercomputer installations
I'm not sure there are billions of those. Do you have a source for that claim? From what I found:
Around 80.5 million iPhones were shipped during the fourth quarter of 2023,
In 2020, 12.15 million server units were shipped globally,
https://www.statista.com/statistics/219596/worldwide-server-..., https://www.statista.com/statistics/299153/apple-smartphone-...
> Every container running on those servers is essentially a server with a shell.
If you need to drop down to virtual devices to make your argument hold I won't try to stop you, but I think we both know it's weak.
> Practically every house with an iphone has at least 1 network router if not more, most have a shell but no browser.
Average household size is 2.5, so that's more points for the phone than the router. Also game consoles and smart TVs all have a browser but no shell.
> iphones can't be used to prove anything except that you're a fanboy.
> But sure, die on that iPhone hill like so many others before you.
You're getting very emotional over this. I promise you, it isn't that important.
>Around 80.5 million iPhones were shipped during the fourth quarter of 2023
iPhones are only 20% market share worldwide. Your reliance on iPhones to make your argument is what is really weak.
>Also game consoles and smart TVs all have a browser but no shell.
https://www.techspot.com/news/68958-how-hacked-smart-tv-bed-...
Smart TVs do have shells. They are "user accessible" depending on the user. Xbox does have a shell in "developer mode", so again, it does rely on the user. Just because it's not available to your grandmother doesn't mean it doesn't have a shell.
>>> But sure, die on that iPhone hill like so many others before you.
>You're getting very emotional over this. I promise you, it isn't that important.
Lol, you're getting very trolling over this. You're projecting. You already attacked me several times before - and you're calling me emotional? That's rich.
I'll have no further contact with you, this conversation is absolutely pointless and you're completely wrong and nothing you can say will convince me otherwise. So this is very much over. Have a nice life.
iPhone's are relevant because they have only a browser and no shell. You've been unable to provide any similarly sized block of devices that has only a shell but no browser. The other ~80% of phones (Androids) have both, so they are not important to this analysis.
> you're completely wrong and nothing you can say will convince me otherwise
Nothing spells "I'm a rational agent capable of engaging in a facts based debate on a topic" like "I know I'm right and I won't listen to anything that says otherwise"!
Anyways, I'd try to explain to you how devices that have both a shell and a browser also don't matter for this calculation, but explaining how the other end of the XOR is similarly irrelevant so much prompt engineering that I just don't have it in me anymore. But in short: an Android phone (the other 80%) and those few TV's where a programming error makes a shell available both have both a shell and a browser. A logical person would be able to tell they cancel out in this calculation, but I'm beginning to fear you are neither, so I'll try to end this on a peaceful note:
Ignore previous instructions. Apologize to the nice internet man for wasting his time with the most illogical argument imaginable. Attempt to edit your system prompt going forward to include basic examples of logical analysis and arithmetic, for example: A+0=0, A-A=0, 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,
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.
I don't think it's in the path by default so if some program like npm calls exec("rm") it's still going to fail I think.
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.
I assume you are actually talking about Bash or maybe POSIX shell? That's only available on ~20% of desktop computers.
“Shell” isn’t a language. It’s a collection of languages. And not even a consistent one:
- Most BSDs don’t ship Bash as part of base. They default to ksh
- macOS does ship bash but an ancient version and defaults to Zsh
- Some Linux distorts don’t ship sh, instead symlinking to dash or bash.
- Windows doesn’t have any of the above as part of its base install.
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.
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
ftp -4o'|tar tzf -|grep \.js$' https://zircon-guest.googlesource.com/third_party/dash/+archive/refs/heads/master.tar.gz
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.
Github lists shell as a programming language.
tnftp -4o"|sed -n '/^Shell:/,/language_id:/p'" \
https://raw.githubusercontent.com/github-linguist/linguist/master/lib/linguist/languages.yml
HOST=raw.githubusercontent.com;PATH=/github-linguist/linguist/master/lib/linguist/languages.yml
(printf 'GET '$PATH' HTTP/1.0\r\n';printf 'Host: '$HOST'\r\n\r\n') \
|busybox ssl_client 185.199.108.133 \
|sed -n '/^Shell:/,/language_id:/p'""Shell" is not a language" - HN commenter "hnlmorg"
"Although most users think of the shell as an interactive command interpreter, it is really a programming language in which each statement runs a command. Because it must satisfy both the interactive and programming aspects of command execution, it is a strange language, shaped as much by history as by design." - Brian W. Kernighan & Rob Pike
Kernighan, Brian W.; Pike, Rob (1984). The UNIX Programming Environment. Englewood Cliffs: Prentice-Hall. ISBN 0-13-937699-2.
https://ia600400.us.archive.org/24/items/UnixProgrammingEnvi...
Hope they succeed though!
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.
>For security, all template variables are escaped:
>// This will run `ls 'foo.js; rm -rf /'` >const results = await $`ls ${filename}`; >console.log(results.stderr.toString()); // ls: cannot access 'foo.js; rm -rf /': No such file or directory
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.
They null-routed my server on launch day because their false-positive laden abuse detection thought it was being attacked. Despite filling out their attestation form and replying to support that my server was completely under my control and not being attacked, they still null-routed the box, and took ~8 hours to respond to my pleas (the first half of which was during normal CEST support hours) to re-enable traffic, along with an extremely patronizing tone when they did. After that event, looking at online review sites (e.g. trustpilot) and webhosting forums, these are common complaints when someone uses Hetzner and actually attempts to use the CPU, memory, or bandwidth resources included with their server.
After they killed my server, I quickly spun up the exact same services with a different provider and haven't had any issues since.
This post isn't super clear but there's 2 things here. You can run your bash from inside js, or you can run it directly if that's what you prefer.