3 ms·

> We've implemented many common commands and features like globbing, environment variables, redirection, piping, and more. Of course on paper that sounds fine.

by 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.
- Aerbil313 3y ago
  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.
  - lf-non 3y ago
    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.
    - Aerbil313 3y ago
      Well yeah, but there’s always something to forcing people to move on to the next thing. I know I’m asking for too much.
    - hnlmorg 3y ago
      I agree. I’ve written about this before but this is what murex (1) does. It reimplements some of coreutils where there are benefits in doing so (eg sed, grep etc -like parsing of lists that are in formats other than flat lines of text. Such as JSON arrays) 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. 1. https://murex.rocks https://murex.rocks
  - abhinavk 3y ago
    I agree. I also increasingly find myself using bat, ripgrep, eza etc even with zsh.
- pdimitar 3y ago
  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.
sureglymop 3y ago
Wait but find isn't a builtin command right? What do you mean by the odds and ends of GNU find not being there? That doesn't depend on the shell, it's an external program being called.
- jackhalford 3y ago
  It does depend on the shell here, bun is reimplementing basic commands to make them cross platform, like rm -rf is not running the rm binary because that doesn’t work on windows
  - sureglymop 3y ago
    Ahh I see now! I thought they were only doing what you're describing for shell builtins. That does seem like a big effort though, now that you mention it...
airstrike 3y ago
> 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
- jchw 3y ago
  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"?
  - avgcorrection 3y ago
    Silence is equivalent to a “no” (posix comp.). That’s documentation enough.
DanielHB 3y ago
I brought a similar question in this thread: https://twitter.com/DanielHoffmann_/status/1749420615029657681 https://twitter.com/DanielHoffmann_/status/17494206150296576... 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

by jchw 3y ago

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.

Aerbil313 3y ago
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.
- lf-non 3y ago
  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.
  - Aerbil313 3y ago
    Well yeah, but there’s always something to forcing people to move on to the next thing. I know I’m asking for too much.
  - hnlmorg 3y ago
    I agree. I’ve written about this before but this is what murex (1) does. It reimplements some of coreutils where there are benefits in doing so (eg sed, grep etc -like parsing of lists that are in formats other than flat lines of text. Such as JSON arrays) 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. 1. https://murex.rocks https://murex.rocks
- abhinavk 3y ago
  I agree. I also increasingly find myself using bat, ripgrep, eza etc even with zsh.
pdimitar 3y ago
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.

sureglymop 3y ago

Wait but find isn't a builtin command right? What do you mean by the odds and ends of GNU find not being there? That doesn't depend on the shell, it's an external program being called.

jackhalford 3y ago
It does depend on the shell here, bun is reimplementing basic commands to make them cross platform, like rm -rf is not running the rm binary because that doesn’t work on windows
- sureglymop 3y ago
  Ahh I see now! I thought they were only doing what you're describing for shell builtins. That does seem like a big effort though, now that you mention it...

airstrike 3y ago

> 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

jchw 3y ago
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"?
- avgcorrection 3y ago
  Silence is equivalent to a “no” (posix comp.). That’s documentation enough.

DanielHB 3y ago

I brought a similar question in this thread: https://twitter.com/DanielHoffmann_/status/1749420615029657681 https://twitter.com/DanielHoffmann_/status/17494206150296576... 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