4 ms·

This will probably sound completely insane, not least of all to people who prefer non-GNU coreutils, but I kinda hope that as uutils matures, some shells will o

by pxc 5y ago

This will probably sound completely insane, not least of all to people who prefer non-GNU coreutils, but I kinda hope that as uutils matures, some shells will offer an option to compile in the uutils rewrites as builtins. Especially for newer shells and shells that want to target Windows in a first-class way, that could be a real portability win.

deleted 5y ago
[deleted]
smt88 5y ago
Why is WSL[1] insufficient for Windows portability? 1. https://docs.microsoft.com/en-us/windows/wsl/about https://docs.microsoft.com/en-us/windows/wsl/about
- dagw 5y ago
  WSL is great if you want/need a full Linux environment. It is quite heavy and probably overkill if all you want is to use some coreutil commands from the Windows terminal.
  - tyingq 5y ago
    Gitbash is a relatively nice solution for this.
  - mkl 5y ago
    WSL1 is very light in my experience.
- pxc 5y ago
  I wasn't primarily concerned with Windows portability, but with the portability of scripts altogether, and no longer having to concern oneself with variations in coreutils versions for at least some scripts, even if they run on multiple platforms. But to answer your question about Windows: Because requiring an emulation layer is a huge step up in complexity from being able to distribute your shell as a single static binary which is just a few MB. Right now Elvish and Nushell, for example, can be deployed on Windows as binaries that don't require any external dependencies, any installation procedure, or any configuration. If they could link against uutils statically, they could also come with basic utilities without having an environment to manage. WSL (along with MSYS2 and Cygwin) is deeply stateful. Now to make sure everything is working you have to check the compatibility of your whole system, and the versions of coreutils can still vary in addition to the version of the shell interpreter. WSL2 also requires virtualization, which can complicate using it under virtual machines. You may not want everything you run under your shell to depend on WSL, which is also happens with WSL2. Even with WSL1, a script that requires a chroot environment to deploy and run it is way less portable than one that doesn't.
- steveklabnik 5y ago
  Because WSL is not Windows. It's a fantastic tool but it's not actual native Windows support. I use Windows to develop software on a daily basis, and I don't have WSL installed at all.

by pxc 5y ago

deleted 5y ago

[deleted]

smt88 5y ago

Why is WSL[1] insufficient for Windows portability? 1. https://docs.microsoft.com/en-us/windows/wsl/about https://docs.microsoft.com/en-us/windows/wsl/about

dagw 5y ago
WSL is great if you want/need a full Linux environment. It is quite heavy and probably overkill if all you want is to use some coreutil commands from the Windows terminal.
- tyingq 5y ago
  Gitbash is a relatively nice solution for this.
- mkl 5y ago
  WSL1 is very light in my experience.
pxc 5y ago
I wasn't primarily concerned with Windows portability, but with the portability of scripts altogether, and no longer having to concern oneself with variations in coreutils versions for at least some scripts, even if they run on multiple platforms. But to answer your question about Windows: Because requiring an emulation layer is a huge step up in complexity from being able to distribute your shell as a single static binary which is just a few MB. Right now Elvish and Nushell, for example, can be deployed on Windows as binaries that don't require any external dependencies, any installation procedure, or any configuration. If they could link against uutils statically, they could also come with basic utilities without having an environment to manage. WSL (along with MSYS2 and Cygwin) is deeply stateful. Now to make sure everything is working you have to check the compatibility of your whole system, and the versions of coreutils can still vary in addition to the version of the shell interpreter. WSL2 also requires virtualization, which can complicate using it under virtual machines. You may not want everything you run under your shell to depend on WSL, which is also happens with WSL2. Even with WSL1, a script that requires a chroot environment to deploy and run it is way less portable than one that doesn't.
steveklabnik 5y ago
Because WSL is not Windows. It's a fantastic tool but it's not actual native Windows support. I use Windows to develop software on a daily basis, and I don't have WSL installed at all.