17 ms·

The Bun Shell

• Self-Perfection 3y ago
  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?
  • cerved 3y ago
    An absolutely ludicrous point, shells have some of the fastest startup times of all processes
    • shzhdbi09gv8ioi 3y ago
      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 ;-)
      • cerved 3y ago
        Why would you need to optimize the config? I'm not talking about running an interactive shell.
        • shzhdbi09gv8ioi 3y ago
          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.
          • cerved 3y ago
            They were quoting the article, which complains that "shells are too slow to start", with examples of running echo in non-interactive shells. Nobody is talking about the startup time of interactive shells.
      • billywhizz 3y ago
        on my crappy old i5 dell laptop running ubuntu 22.04 i see ~1.5ms for bash and ~1ms for sh. i dunno where these really bad numbers are coming from tbh.
  • vojvod 3y ago
    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.
• gnarlouse 3y ago
  Can somebody explain why they’re attributing ZSH to macOS? It’s clearly cross platform
  • stephenr 3y ago
    The only guess I have is because it's the default interactive shell on macOS, while bash is probably more common on GNU systems. 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.
    • gnarlouse 3y ago
      > default interactive shell Is that fairly new? I thought the default shell was bash.
      • stephenr 3y ago
        Since Catalina, released in 2019.
  • chasil 3y ago
    It would be equally appropriate/wrong to say that mksh, the MirBSD Korn shell, is Android's system shell. The manual page for mksh also mentions Android in the introduction for those who do not understand the role.
  • mejthemage 3y ago
    Thank you. As someone who avoids Apple at all costs but loves zsh, this really rubbed me the wrong way. Pretty sure MacOS used to use bash too.
• nathan_phoenix 3y ago
  For 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 https://github.com/sindresorhus/execa [2]: https://github.com/google/zx https://github.com/google/zx
  • neongreen 3y ago
    I’m using zx and the API seems very similar to what is described in the post. Which bun also acknowledges here: https://github.com/oven-sh/bun/blob/main/docs/runtime/shell.md 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.
  • qazxcvbnm 3y ago
    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 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 https://github.com/TritonDataCenter/node-spawn-async and unmaintained.
    • kvakil 3y ago
      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=&projects=&template=1-bug-report.yml https://github.com/nodejs/node/issues/new?assignees=&labels=...
• askonomm 3y ago
  I didn't know, but apparently you can execute a function in JS without parentheses using upticks (`), e.g: functionName`param` and whatever is inside of the upticks get sent to the function as an array. It's also what Bun is doing with it's $ (dollar sign) function for executing shell commands. There's so much weird syntax magic in JS.
  • n0w 3y ago
    These are called "tagged templates": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    • askonomm 3y ago
      Ah! There's a lot more to this than just executing a mere function it seems. Consider me educated!
    • MobiusHorizons 3y ago
      Tagged templates are really cool. They are a reasonably simple extension of template strings, which allow constructing strings very easily by allowing arbitrary code to be put inside a ${} block inside of template strings (ones that begin and end with backticks ` instead of single or double quotes). 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.
      • 8n4vidtmkvmk 3y ago
        I just wish they had something like pythons triple quotes or here docs or c++ r strings. A single backtick makes it hard to use backticks inside the string
• skybrian 3y ago
  I guess this is too new for there to be any language documentation yet? Or perhaps I missed it. I'm wondering if it's picked up any ideas from oil shell [1]. [1] https://www.oilshell.org/ https://www.oilshell.org/
  • dharmab 3y ago
    There's a short doc here https://bun.sh/docs/runtime/shell https://bun.sh/docs/runtime/shell but it notes that the shell is not yet feature-stable.
• worksonmine 3y ago
  It feels like the people behind bun are trying to differentiate from node so much that they sometimes don't stop to ask why. 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.
  • neongreen 3y ago
    The most common usecase is probably “I have `rm` in the scripts section of package.json, and it doesn’t work on windows.”
    • LudwigNagasena 3y ago
      > Bun provides a limited, experimental native build for Windows. > # 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!
      • 8n4vidtmkvmk 3y ago
        I don't think that's permanent. Eventually they'll have a stable release on windows
  • afavour 3y ago
    It does feel like Bun is trying to do a lot. And when the company depends on VC funding I think it’s fair to question whether you want to rely on them for a core project functionality.
  • 8n4vidtmkvmk 3y ago
    I'd personally rather write my long shell scripts in js for my js-based project. And I wouldn't bring in grep to run a regex either but I'd use it to run a myriad of other tools that aren't implemented in js.
• jchw 3y ago
  > 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 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.)
  • netghost 3y ago
    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.
  • abhinavk 3y ago
    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.
• MuffinFlavored 3y ago
  This is like... eval? I thought eval was bad?
  • ants_everywhere 3y ago
    Eval with an uncanny valley shell whose commands behave similar to the way you expect, but not necessarily exactly the way you expect.
  • lioeters 3y ago
    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.
  • voiper1 3y ago
    Nope - there's at least one layer of safety: >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
  • seniorsassycat 3y ago
    Potential User input is separated from code in the tagged template. $`rm ${"dir"}` is not the same as $`rm dir`
• Jarred 3y ago
  I work on Bun - happy to answer any questions/feedback
  • helsontaveras18 3y ago
    How do you ensure cross platform compatibility under the hood?
    • Jarred 3y ago
      We implement a handful of the most common commands like cd, rm, ls, which, pwd, mv. Instead of using the system-provided ones, it uses ours. Unlike zx/execa, we have our own shell instead of relying on a system-installed one.
      • reactordev 3y ago
        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?
        • Jarred 3y ago
          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 implemented similarly. We expect most scripts to be simple one-liners since you can use JS for anything more complicated.
          • reactordev 3y ago
            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.
• metaltyphoon 3y ago
  So is this akin to Powershell Core but having JS as a language!
• frompdx 3y ago
  Interesting. It reminds me a bet of janet-sh. I can see the utility if you are working with JavaScript or TypeScript. It might even work with ClojureScript using shadow-cljs. https://github.com/andrewchambers/janet-sh https://github.com/andrewchambers/janet-sh
• brailsafe 3y ago
  Using 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
  • BirAdam 3y ago
    Plenty of people use Windows for development, Linux for development and gaming, and macOS for everything including servers. It’s all about preference.
    • Ygg2 3y ago
      Want to use a cool dev tool on Windows boils down to, can you host a Linux VM? 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.
  • LucasOe 3y ago
    If you want bash like syntax, you can always run msys2 / Cygwin / WSL on Windows. But 99% of the time I just need to run basic commands like git and maybe pipe them to ripgrep or fzf, and frankly the PowerShell is fine for that. For anything more complicated, I'll write a script in Python or maybe JavaScript anyway, so I don't really care what shell I use as long as I can customize it and it can run basic commands. And if you don't like PowerShell, there's Nushell.
    • RadiozRadioz 3y ago
      You could save yourself a lot of time by learning more bash so you didn't have to break out a programming language any time things get more complicated than piping into grep.
    • marwis 3y ago
      Actually Powershell is terrible for piping anything native. It will damage whatever data you pipe. 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.
• benpacker 3y ago
  I like this, and I like Bun, and I’m going to use this, but I’m nervous about whether Bun’s ultimate share of the server-side cloud Javascript will be big enough to sustain the maintenance surface area they are carving out for themselves. Hope they succeed though!
• jftuga 3y ago
  Their info about "rm -rf" not working in Windows is slightly misleading. In PowerShell, you can accomplish this by running: rm -r -fo my-folder-name
  • ARandomerDude 3y ago
    How many Linux/Mac devs know that? We live in a left-pad world, of course people will install a package to get a simple job done.
    • charrondev 3y ago
      This is mostly useful to developers that don’t develop on windows. Typically server side and browser based JavaScript programs are deployed on Linux systems in production. 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.
  • aarjithn 3y ago
    Well, it’s still not “rm -rf” right? Why is it misleading then? 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
  • Gabrys1 3y ago
    The reason I used rimraf was it was a way to make JS delete all files in the directory. Why would I need to think to shell out to "rm -rf dir" and be responsible for argument escaping, error handling, different shells, etc. If that's what the library does, ok, but it can do it in any way the library devs decided was best. I offloaded that decision to them (putting more trust in them to do it right than in myself).
• LilBytes 3y ago
  [flagged]
• 38 3y ago
  doesn't work with Windows: https://github.com/oven-sh/bun/issues/43 https://github.com/oven-sh/bun/issues/43
  • oblio 3y ago
    This is super confusing considering the text in the article.
    • 8n4vidtmkvmk 3y ago
      There's an unstable windows build of bun. I imagine they're working out the final few kinks but want to make sure this new lib is ready to go now
• o11c 3y ago
  Note that the `hyperfine` example is actually measuring two nested shells. Unless hyperfine implements a shell-parser of its own, of course.
  • Jarred 3y ago
    The -N flag tells hyperfine to not run it in a shell, which means it is not nested.
• afavour 3y ago
  [flagged]
  • deleted 3y ago
    [deleted]
• blackhaj7 3y ago
  Love that bun just implements anything that could be useful. They are busy building useful stuff whilst others pontificate about what they should/shouldn’t build
  • rco8786 3y ago
    Seriously. Like it’s just one continuous hack week over there.
• arrakeen 3y ago
  if you're writing "await" before every function call maybe that should be the default.
  • deleted 3y ago
    [deleted]
  • dumbo-octopus 3y ago
    No. Places where execution can be interrupted should be obvious and explicit.
  • fijiaarone 3y ago
    Or maybe synchronous should be the default.
    • 8n4vidtmkvmk 3y ago
      Isn't that what he's implying?
  • cutler 3y ago
    Or maybe a wake-up call that something is off. Shell scripting is a domain where impertive/procedural code shines.
• deleted 3y ago
  [deleted]
  • deleted 3y ago
    [deleted]
• viraptor 3y ago
  I 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.
  • skybrian 3y ago
    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.
    • tipiirai 3y ago
      JSON is a terrible configuration file format. Property names must be quoted, tons of brackets and commas, a mistake comma breaks it, no comments allowed, etc..
      • andyfleming 3y ago
        JSON5 is a more reasonable format for config files, in my opinion.
        • tipiirai 3y ago
• hipadev23 3y ago
  > On a Linux x64 Hetzner Arch Linux machine, it takes about 7ms: hyperfine --warmup 3 'bash -c "echo hello"' 'sh -c "echo hello"' -N On my home machine and a mid-range AWS EC2 instance, the echoes run in ~0.5ms for bash and ~0.3ms for sh. 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.
  • jgalt212 3y ago
    It's a been a long time since I read a post where someone bashes Hetzner. Usually they are well received. We use their VMs as back up servers, so not really pushing them hard. The most negative things I've read about them is they have much stronger KYC than AWS.
    • antoniojtorres 3y ago
      Agreed, have been a hetzner customer for years running a myriad of services there without issues.
      • fijiaarone 3y ago
        People were running high power severs and databases on pentium 2s. Most cloud servers and programming frameworks) don’t exceed their performance.
    • hipadev23 3y ago
      Not trying to derail the thread, but having used a variety of dedicated, virtualized, and shared hosts since the mid 90's, Hetzner was hands-down the worst experience I've ever encountered. Their KYC process is indeed arduous but that's not my complaint, in fact I naively believed it meant they took things seriously. 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.
• 1vuio0pswjnm7 3y ago
  "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.
  • dumbo-octopus 3y ago
    I'd argue the opposite: more computers have an end-user accessible JavaScript engine (a browser) than an end-user accessible shell.
    • leptons 3y ago
      It really depends on how you define "computer".
      • SCUSKU 3y ago
        Let's not forget, "3 billion devices run Java"
      • dumbo-octopus 3y ago
        Can you give an example of a device that has an end-user accessible shell, but not an end-user accessible browser? Every iOS device is the opposite.
        • leptons 3y ago
          Your definition of "computer" seems to be too narrow. "A computer" does not have to have a shell, run linux, windows, or macos - "a computer" can be an embedded 8-bit SOC. 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.
• jcadam 3y ago
  Javascript shell?! It's like c shell, only worse.
• binary132 3y ago
  This is neat, but a) it strikes me that what's powerful about shell scripting is that it lets you easily wrangle multiple independent utilities that don't need to be contained within the shell stdlib (maybe I'm missing something but I didn't see any emphasis on that), and b) that embedding a language as a string inside another language is very rarely a good UX. I like that it's a really portable shell though. Shell portability is actually a pretty big problem.
• CuriouslyC 3y ago
  This looks very cool on the surface. There are a lot of systems out there with a mishmash of javascript and shell, those systems are stitched together in arbitrary ways, and it can often make them hard to debug and test. This looks like it'll make it easier to write and test those integrations, which is a 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.
• deleted 3y ago
  [deleted]
• mythz 3y ago
  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 https://www.npmjs.com/package/shx
  • notpushkin 3y ago
    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 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)!
• lucasyvas 3y ago
  This looks exactly like zx by Google. And that's probably a good thing. https://github.com/google/zx https://github.com/google/zx
  • nateb2022 3y ago
    Great point! According to https://github.com/oven-sh/bun/blob/b433beb016470b87850f3c018974de5f2e355d52/docs/runtime/shell.md?plain=1#L359 https://github.com/oven-sh/bun/blob/b433beb016470b87850f3c01..., Bun Shell took inspiration from zx[0], dax[1] and bnx[2] [0]: https://github.com/google/zx https://github.com/google/zx [1]: https://github.com/dsherret/dax https://github.com/dsherret/dax [2]: https://github.com/wobsoriano/bnx https://github.com/wobsoriano/bnx
  • lambda 3y ago
    Being in the Google GitHub org doesn't mean "by Google", it means "by someone who works at Google."
    • redder23 3y ago
      To me its the same thing, they are paid my Google to code stuff the is put in their org and not their private accounts/orgs so to me this IS in fact "by Google".
    • ycuser2 3y ago
      But doesn't he get paid by Google to code this?
      • atorodius 3y ago
        They do, otherwise it won’t be in that repo
      • FiloSottile 3y ago
        No, something being under github.com/google means the person who started it was paid by Google, not paid by Google to code this. Google contracts (like most tech contracts in the US) have ridiculously broad IP assignment clauses, so unless you go through a lengthy process to request Google disown something, they own anything you code, and they insist you open source your things under github.com/google. 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.
• lloydatkinson 3y ago
  [flagged]
  • 8n4vidtmkvmk 3y ago
    To what end?
    • lloydatkinson 3y ago
      Unfortunately my comment was flagged (preparing to exactly what I meant) so there’s no point me elaborating further in this thread, perhaps another one.
• yankaf 3y ago
  [flagged]
• cutler 3y ago
  JS everything. No thanks. Show me a one-liner in Bun which comes anywhere near your average bread & butter bash + Linux utils pipeline. Async my have its uses but shell scripts ain't one of them. Shell scripts are impreative/procedural for a reason - sequential processing.
  • 8n4vidtmkvmk 3y ago
    That's literally what this is though. You can run your bash script using bun, and it might even run faster because it's actually implemented in zig. 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.
• TheAceOfHearts 3y ago
  When I need shell-like utilities from my JS scripts I've previously used shelljs [0]. It's neat that Bun is adding more built-in utilities though. [0] https://github.com/shelljs/shelljs https://github.com/shelljs/shelljs
• anon-3988 3y ago
  I am pretty Python already have all of these? One could just write Python CLI that wraps Python stdlib to do all of these.
  • Cpoll 3y ago
    Python's subprocess, os.system, etc. offload the work to your system's shell. Bun, on the other hand, is running the scripts in its own runtime.
• floof 3y ago
  Node's `execSync` is pretty much this easy to use as well.
• tipiirai 3y ago
  I love Bun. I no longer use Node for development. Hardly any gotchas anymore. It's just faster all over. Especially `bun test`. Highly recommended. Thank you @Jarred!
• natrys 3y ago
  > $ hyperfine --warmup 3 'bash -c "echo hello"' 'sh -c "echo hello"' -N 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.
• forrestthewoods 3y ago
  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 bash hell 100% of the time.
  • 8n4vidtmkvmk 3y ago
    That's part of the beauty of bun though. You can write it in typescript instead and run it directly with bun. And now with this you can weave in a call to a binary very easily if you need
  • mike_hearn 3y ago
    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.
  • shzhdbi09gv8ioi 3y ago
    I been using golang lately to replace shells. 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 Cons: * not bash script :-)
• postepowanieadm 3y ago
  js is the new perl
  • 8n4vidtmkvmk 3y ago
    I wish they'd adopt pcre
• pjmlp 3y ago
  Perl and Python already went through this path without much uptake.
  • mst 3y ago
    I've seen quite a lot of "shell but in perl" and "shell but in python" in the wild, but also I think this is primarily aimed at "this particular utility that ships with $library would most naturally be a shell script but it's a lot more convenient overall to have a nice way to write something similar-ish-looking that shares the interpreter with everything else." If nothing else it'll make development-side package.json commands easier and nicer, which is still IMO a net win.
• mjburgess 3y ago
  fyi, the src: https://github.com/oven-sh/bun/tree/main/src/shell https://github.com/oven-sh/bun/tree/main/src/shell
• simonjgreen 3y ago
  Minor tangent, but plucked from that article, why is ‘rimraf’ downloaded 60m+ time a week?! Why is that a thing that need a library? (Asking as a systems guy, not a programmer)
  • httgp 3y ago
    It’s quite often used in npm scripts to cleanup stuff (say, between builds), and many developers prefer that over native solutions like `rm` and `del` as it gives them a cross-platform way of cleaning up files and folders.
  • M4v3R 3y ago
    The OP already explained that - because people want their package.json scripts to be cross-platform, and „rm” does not exist on Windows. So instead you add rimraf to your dependencies and use that instead of rm in your scripts.
  • goenning 3y ago
    And why is it not called `rmrf`
  • mike_hearn 3y ago
    Which languages have a recursive delete in their standard library, other than shell? Do any? HShell (see other comments) also implements its own rm() function because the JDK standard library is too low level to support something like that.
  • diroussel 3y ago
    Yes 60m downloads is a lot of downloads. But it’s not 60m developers manually clicking the download link every week. Not is it 60m times that “npm install rimraf” has been called. What is happening is that many projects, some big some just hello world tutorials, have listed rimraf in the package.json file for that project. Then when “npm install” is run, all the packages get downloaded. And what is more, many people build their software in CI builds, like travisci, circleci, or GitHub actions. The build scripts will also then downloaded everything listed in package.json. And if you do multiple builds a day, then that’s multiple downloads each day. 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 https://www.npmjs.com/package/rimraf
• RadiozRadioz 3y ago
  Great, it's approaching the ergonomics of what Perl has offered for decades. And Perl still does it better.
  • Culonavirus 3y ago
    Um, what? Perl in 2024 is just (far) worse Php. Or why just not use Python at that point?
    • Aerbil313 3y ago
      Raku (Perl 6) is a unique and great language for single developer productivity.
    • mst 3y ago
      I ... am not sure which of the three languages you're familiar with, but I don't think that's remotely correct. 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.
• guax 3y ago
  Shells are a solved problem!!
• devnonymous 3y ago
  My understanding from reading the post is that this is a shell in the same way python or perl or php or pgsql or mysql prompt is a shell. This isn't an interactive shell afaict. 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?
• baudaux 3y ago
  Bash works well in https://exaequos.com https://exaequos.com. It is compiled in WebAssembly
  • hnlmorg 3y ago
    Cool project but it’s completely impossible to navigate back. Something on that page is spamming my browsers back button history
    • baudaux 3y ago
      Strange, history is not used. Which browser are you using ?
      • OscarDC 3y ago
        I have the same back-button issues on both Firefox and Chrome (on linux if it matters) when going to this website. Multiple pages in history are e.g. just black screens.
      • hnlmorg 3y ago
        Safari on iOS.
        • baudaux 3y ago
          Thank you for your feedback. I will check
• simplyinfinity 3y ago
  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.
  • pc_edwin 3y ago
    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.
  • mst 3y ago
    The article starts by mentioning the programmatic interfaces, but the point here is to be better able to write quick, clear scripts, not full programs. 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.
• mike_hearn 3y ago
  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/ 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<String> 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!
• ianwalter 3y ago
  Really cool. How would you use config files from other shells like .zshrc? We use direnv and mise to scope binary versions to project directories and just wondering how stuff like that would work.
• acomagu 3y ago
  I'm just waiting for a world where everyone uses Plan9's rc shell...
• 4m1rk 3y ago
  With Xonsh why would I want to use the this?