oils VS PowerShell

Switching away from being bash compatible would be really unexpected. Maybe something like http://www.oilshell.org/ has a chance though?

If we were breaking away from the old style shells completely, then https://www.nushell.sh/ would be my preferred upgrade.

bash and readline - Chet Ramey. Both originally by Brian Fox https://twobithistory.org/2019/08/22/readline.html

maybe less of a bus factor now with OSH approaching feature/speed parity and having more maintainers https://www.oilshell.org/

Hm I'm not familiar with that library (or really any others in the landscape). Why pick that one?

I'd be interested in a review / survey, and the strategy for testing. Basically the tests should "argue" that the code is correct, and documentation / blog posts also count!

(I'm honestly not sure how hard it is to make a correct big num library. But I think the original article in this series said there were probably bugs, so I'm guessing it's not trivial)

To give a flavor, we publish test results and and coverage numbers like this [1], and any new library should be consistent with this:

https://www.oilshell.org/release/0.22.0/quality.html

Our GC runtime has less than 5000 lines of hand-written C++ now, so any solution should be in proportion to that. That is, we probably wouldn't take on 3000 lines of code just for big nums.

So we favor correctness over performance. Hopefully there would be little perf loss in the small int case, but it's OK if the big int case is slow. It's the rarer case for sure.

---

As far as the grant, we pay in 2500 euro or 5000 euro increments, and I don't try to parse it any more than that. I care about the result, not if it's easy for a particular person :)

For example earlier this year we had a contributor Justin who worked on the pretty printer, with Wadler's algorithm (which I was unfamiliar with).

https://www.oilshell.org/blog/2024/06/release-0.22.0.html

And he had co-authored a paper on pretty printing, so it was probably not too difficult overall. But that's a good thing as far as I'm concerned!

So if you or anyone else thinks it's easy, please feel free to contact me / play around with the code, etc.

https://github.com/oilshell/oil/wiki/Where-Contributors-Have...

[1] our unit test coverage is reported at 83% or so, but we favor "exterior" tests, so it's really close to 95% or 99%. Also of course line coverage is a misleading metric.

All these programs will output ANSI color if `isatty(stdout)` is true (roughly speaking).

Most people didn't quite get that -- they thought we should use "nREPL" or something -- but my opinion is that you really need a specific protocol to communicate with a shell, because a shell spawns other programs you still want to work.

---

Here is a pure Python 3 implementation of the recv() side of FANOS in only ~100 lines

https://github.com/oilshell/oil/blob/master/client/py_fanos....

It uses the recvmsg() binding . I'm pretty sure node.js has that too? i.e. it has Unix domain socket support

---

Anyway, thanks for taking a look - we're interested in feedback!

This is similar to how https://www.oilshell.org/ is written

There are two complete implementations

1. one that runs under a stock Python interpreter (which doesn't use static types)

2. one that's pure C++, translated from statically typed Python code, and from data structures generated in Python

In the second case, everything before main() is "burned off" at build time -- e.g. there is metaprogramming on lexers, flag parsers, dicts, etc. that gets run and then into static C data -- i.e. pure data that incurs zero startup cost

Comparison to Pre-Scheme: https://lobste.rs/s/tjiwrd/revival_pre_scheme_systems_progra... (types, compiler output, and GC)

Brief Descriptions of a Python to C++ Translator - https://www.oilshell.org/blog/2022/05/mycpp.html

...

And related to your other point, I remember looking at Racket's implementation around the time it started the Chez Scheme conversion. I was surprised that it was over 100K lines of hand-written C in the runtime -- it looked similar to CPython in many ways (which is at at least 250K lines of C in the core).

Is it an array of strings because it's a "simple command"? Or does it behave like an assignment? You get two different answers depending on how you look at it.

The bottom line is that assignment builtins are special and they don't follow the normal rules of simple commands. Shells have differed, but POSIX decided on this awhile ago.

---

This is all of course mind numbing trivia that has no real reason for existing ... YSH fixes it, and it's now pure native C++, no more Python.

YSH Doesn't Require Quoting Everywhere - https://www.oilshell.org/blog/2021/04/simple-word-eval.html (Oil was renamed to YSH since this blog post was written)

Simple Word Evaluation in Unix Shell - https://www.oilshell.org/release/latest/doc/simple-word-eval...

In YSH you can tell just by looking it's a single string or an array.

    ls $a  # identical to ls "$a"

Oils is a different approach to this - the base “OSH” language is pretty much identical to bash, and then you can incrementally opt in to more checks and QOL improvements.

The key selling point is that you never have to totally rewrite your existing bash scripts - there’s an incremental upgrade path.

https://www.oilshell.org/

While I don't agree with most of your analysis - in particular for the second example, I'd invite you to read its explainer that goes into much more depth (https://elv.sh/learn/scripting-case-studies.html#update-serv...) - I think you might be more interested in the Oil Shell project, which is trying to chart a smooth upgrade path from bash: https://www.oilshell.org

I think we simply can't say for sure which path is better for the future of shells, and I'm quite excited by the fact that different projects are exploring different directions. I will just stick to the path I find best and won't try to convert you :)

Some related references (on a somewhat messy wiki page) - https://github.com/oilshell/oil/wiki/Compact-AST-Representat...

Feel free to add others

PowerShell is MIT licensed, cross-platform Windows, Linux, macOS compatible, and you can download it in various installers and packages here: https://github.com/PowerShell/PowerShell/releases

for anyone who wants to try the newer version on Windows, get either Windows Terminal (from Microsoft Store or Github releases: https://learn.microsoft.com/en-us/windows/terminal/install) or Visual Studio Code. The classic Windows' command prompt console host engine just can't do Unicode and fonts and colours and Unix shell escape sequences.

After that, find something which will immediately trigger you to froth at the mouth, hurry onto some Microsoft forum and post about how Microsoft is the devil. Here's some popular choices: ('curl' and 'wget' on Windows override the real programs with M$ imposters). (gci doesn't support the parameters of either dir or ls). (aliases work differently to Unix shells). (almost everything works differently to Bash). (gci -recurse is frustratingly slow). (it doesn't have a CLI text editor like nano). (you don't understand that GNU and Unix utilities aren't "Bash"). (there isn't any sudo because Windows isn't Linux). (Execution policies are annoying). (it doesn't use UTF8 everywhere always). (backslash, the one true Unix escape character isn't PowerShell's escape character). (Line endings aren't Unix line endings). (having to use sigils to disambiguate between shell and code is worse than Python for coding and worse than Bash/cmd for shelling). (You want > to be both numeric comparison and/or Unix shell IO redirect and it's not). (you hate Verb-Noun and the one true way is Noun-Verb). (It's verbose which you hate, but the elastic syntax one-liners are unreadable which you hate, it should have exactly the right amount of verbosity which coincidentally is exactly the amount you are comfortable with).

Moving on from there, avoid falling for the tempting usermode filesystem equivalent, which is abandoned and only exists for backwards compatibility making everything slower. Avoid falling for the declarative host config system Desired State Configuration (DSC) which is semi-abandoned and only hangs around for backwards compatibility. Control your enthusiasm about .NET/C# LINQ in a shell, because nope. Prepare yourself for the weirdness of a programming language which has shell style dynamic scoping instead of lexical scoping, shell style output handling where all output goes to the pipeline, pipeline obsessed array unrolling which spills the contents of containers all over the floor if you aren't paying attention, having to learn that there's more to output than just stdout and stderr and that the host and pipeline are different outputs. Prepare your armoured-toe boots for a large number of footguns and bugs in what is an intricate and complex shell/scripting language mashup.

Moving on from there, it's a REPL:

    $x = 5

PowerShell is so alien to an experienced bash/zsh/etc. user that it's an entirely different language not any kind of drop-in replacement. Its designers also refuse to add simple things to make the switch any easier (e.g. https://github.com/PowerShell/PowerShell/issues/3316).

Not necessarily:

1. UNIX-compatibility aliases like "ls -> Get-ChildItem" and "cat -> Get-Content" are not defined in PowerShell on Linux or macOS. For a complete list of these, see the PowerShell source code[1] (look for "#if !UNIX").

2. A number of aliases from PowerShell ≤ 5.1 were removed in PowerShell Core (≥ 6.0), including the particularly annoying "curl -> Invoke-WebRequest" (conflicts with curl.exe) and "sc -> Set-Content" (conflicts with sc.exe).

[1] https://github.com/PowerShell/PowerShell/blob/8ea1598964590b...

and do a no-install copy-paste deployment of powershell 7 and modules. (I'm not saying you should do this instead of using Lua, just that you can).

[1] https://github.com/PowerShell/PowerShell/releases

msiexec.exe /package https://github.com/PowerShell/PowerShell/releases/download/v7.2.6/PowerShell-7.2.6-win-x64.msi /quiet ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL=1 ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL=1 ENABLE_PSREMOTING=1 REGISTER_MANIFEST=1 USE_MU=1 ENABLE_MU=1 ADD_PATH=1

This smells like when PowerShell aliased curl and wget to a completely different command, with incompatible arguments.

https://github.com/PowerShell/PowerShell/pull/1901

PowerShell is available on macOS and Linux as well (source on Github: https://github.com/PowerShell/PowerShell). It may not be as well-integrated with things like system services management, but the language still works well. You can still use all the command line tools you're used to on Linux, of course.

nushell does look interesting, though the lack of a .deb repository does put it pretty low on my to-do list.

Issue #7940 discusses potential improvements to array slicing.