The shell that would make me most excited is a cross-platform shell that looked 75% like bash. Give me cross-platform mkdir, rm -rf, pipes, loops, redirection, variable declaration, env variables, subshell syntax, string interpolation, whatnot and I’d be pretty happy. Bash syntax is just so ingrained (not just personally but at 90% of workplaces) at this point all the benefits of learning a new syntax just to have a cross-platform shell just don’t seem worth it.
While WSL exists, I’ve had some difficulty installing WSL on various machines. It has worked on some and not worked on others.
Another goal is that the scripts work in CI environments so your build scripts and test scripts are unified across Windows/Mac/Linux.
Sorry, I meant msys2. It’s easy to get confused. mingw is effectively dead, mingw-w64 is the alive and well fork, and msys2 is the shell that builds on top of mingw-w64. Ah, and let’s not forget cygwin, something that had relevance once upon a time, but no longer has a reason to exist and now only serves to add needless complication to anyone who chooses to inflict it to their workflow.
It’s a very heavyweight way to implement Unix semantics on Windows. WSL gets you actual Linux binaries (be it on NT or a VM) easy, MSYS/mingw-w64 gets you POSIXy compat on top of Windows without living in this slow alien world Cygwin does.
Unfortunately it’s the exact one I meant to completely describe the opposite of. They made up new names for commands, they have a new syntax. It’s a more verbose and structured language like Powershell. Don’t get me wrong I’m a PL nerd and everything-is-a-string offends me. But I also like quick and easy shell scripts and nushell and powershell just aren’t that for me.
I also dislike “eveything is a string”, and I am certainly found of PowerShell vibes, but sometimes a man just needs to grep some shit. Maybe it’s lack of practice, but PowerShell just doesn’t feel as natural on the fingers when you’re chaining shit into a throw away command.
I think you should give it a try. Nushell is actually shorter for more complex stuff, as it is structured. The builtin helpers work on everything too, so you don’t really have to think about the types that much. For example to sum a dirs size: ls | get size | math sum
Fwiw ruby has a great cross platform story, and enough perl inheritance that it works as a scripting language. That said, it doesn’t abstract away the difference between creating a Cron job, scheduled task in windows task scheduler - or creating a systemd unit or service out of the box.
Given all the text about windows compatibility in their post, it’s a bit surprising, but bun doesn’t work on windows https://github.com/oven-sh/bun/issues/43 so that idea is a long way away.
Cross-platform: works on Windows, Linux & macOS. Instead of rimraf or cross-env’, you can use Bun Shell without installing extra dependencies. Common shell commands like ls, cd, rm are implemented natively.
The shell that would make me most excited is a cross-platform shell that looked 75% like bash. Give me cross-platform
mkdir,rm -rf, pipes, loops, redirection, variable declaration, env variables, subshell syntax, string interpolation, whatnot and I’d be pretty happy. Bash syntax is just so ingrained (not just personally but at 90% of workplaces) at this point all the benefits of learning a new syntax just to have a cross-platform shell just don’t seem worth it.While WSL exists, I’ve had some difficulty installing WSL on various machines. It has worked on some and not worked on others.
Another goal is that the scripts work in CI environments so your build scripts and test scripts are unified across Windows/Mac/Linux.
Sounds like you are describing mingw-w64
I haven’t tried to use it in over a decade. I’ll have to give it another shot!
Sorry, I meant msys2. It’s easy to get confused. mingw is effectively dead, mingw-w64 is the alive and well fork, and msys2 is the shell that builds on top of mingw-w64. Ah, and let’s not forget cygwin, something that had relevance once upon a time, but no longer has a reason to exist and now only serves to add needless complication to anyone who chooses to inflict it to their workflow.
Why is Cygwin irrelevant
It’s a very heavyweight way to implement Unix semantics on Windows. WSL gets you actual Linux binaries (be it on NT or a VM) easy, MSYS/mingw-w64 gets you POSIXy compat on top of Windows without living in this slow alien world Cygwin does.
Presumably because of things like WSL and Docker
Well, I think the burden of proof works the other way around. Why is Cygwin relevant?
The question sounds to me like a request for elaboration, not justification.
I’m fairly sure it still covers a larger API surface area than mingw and friends
busybox has a native Windows port but it bundles ash, not bash (75% !?).
busybox and busybox-w32?
I think you’re describing Nushell. It is really cross platform when installed with uutils/coreutils.
I use uutils on my Linux system as well, it makes the help messages much more consistent and better (compared to GNU coreutils), IMO.
Unfortunately it’s the exact one I meant to completely describe the opposite of. They made up new names for commands, they have a new syntax. It’s a more verbose and structured language like Powershell. Don’t get me wrong I’m a PL nerd and everything-is-a-string offends me. But I also like quick and easy shell scripts and nushell and powershell just aren’t that for me.
I also dislike “eveything is a string”, and I am certainly found of PowerShell vibes, but sometimes a man just needs to grep some shit. Maybe it’s lack of practice, but PowerShell just doesn’t feel as natural on the fingers when you’re chaining shit into a throw away command.
I think you should give it a try. Nushell is actually shorter for more complex stuff, as it is structured. The builtin helpers work on everything too, so you don’t really have to think about the types that much. For example to sum a dirs size:
ls | get size | math sumFwiw ruby has a great cross platform story, and enough perl inheritance that it works as a scripting language. That said, it doesn’t abstract away the difference between creating a Cron job, scheduled task in windows task scheduler - or creating a systemd unit or service out of the box.
Maybe oilshell/osh?
http://www.oilshell.org/cross-ref.html?tag=OSH#OSH
Although looks like windows support depends on wsl: https://github.com/oilshell/oil/issues/122
The other option would be PowerShell everywhere - but that’s not bash-like…
not sure about cross-platform but es-shell is a functional-style bashlike shell that I think is underrated
https://wryun.github.io/es-shell/
If you’re willing to forgo loops and ifs, deno_task_shell might fit the bill
what about cygwin
For bash/js scripts there is also google/zx: https://google.github.io/zx/
And dax does a very similar thing by embedding deno_task_shell
More detailed docs here.
I hope/imagine this will work with the single-file executable feature of Bun: https://bun.sh/docs/bundler/executables
Meaning I could write a script but bundle in the runtime and provide executables for Windows and macOS.
Given all the text about windows compatibility in their post, it’s a bit surprising, but bun doesn’t work on windows https://github.com/oven-sh/bun/issues/43 so that idea is a long way away.
Has that changed now? The shell docs say:
Yeah, looks like it’s all changed recently:
https://twitter.com/bunjavascript/status/1747073096295874990
https://github.com/oven-sh/bun/commits/main/.github/workflows/bun-windows.yml