I don’t mean creating a port of PowerShell, or a clone.
My idea is about a native shell for Haiku written entirely in C++, that can interact with API objects, that can configure the system, that has its own scripting language, and that can automate system tasks.
The effort to create such a tool is great, yes, but the workflow could be greatly simplified. There would be no need to create bindings for other programming languages.
Maybe as a way to extend the current Terminal, so as to not end with many different terminals and avoid that situtation in windows where to some commands you need to open a powershell prompt, or a cmd prompt. Like “One Terminal to rule them all”.
That is why I brought up translators. A translator is essentially a parser frontend for a particular type of data. If source code is the data, reusability of the compiler infrastructure would be a natural extension of it. LLVM-JIT or LibGCCJIT would supply most of the guts to it.
Adding to what I just said above, I feel that programming language infrastructure has been left out of end-user’s experiences for too long. I started with a Commodore 64 and the BASIC ready prompt was all you got for an operating system. Now it’s gone too far off the shallow-end opposite that.
Why would you need JIT or AOT for a shell? An interpreter will be just fine, use less memory, and have a faster startup time (which is important since most shell scripts are either interactive or very short running). To me that looks like going completely in the wrong direction.
A translator for sh syntax? Why not, you know, just run sh when you need to run a shell script? That seems a lot simpler.
The Terminal is independant from what you run inside it.
But we can ask if that is a good idea. If I were to reinvent the shell for Haiku and for the XXIst century, I would not restrict myself to a TTY based terminal that is emulating hardware from the 1930s with some small extensions. I would want something that can display graphics, let me interact with them, maybe reply to my commands with a few buttons I can click when that’s appropriate, let me drag and drop the results of commands instead of having to run them through pipes in complex command line chains, etc. That would not look like a terminal at all.
I use Windows Terminal, you can run powershell, cmd, and even a bash shell from Window subsystem for Linux from it. As for the variation of shells, just use powershell for everything, except for some rare cases where you really need the traditional cmd.exe (are there any?)
It’s not a question of “in the same league”. JITs and compiled code are not better than simple interpreted code in all cases.
When you have short running scripts or interactive commands, you want the execution to start very fast. So you don’t want to spend time compiling it (even just in time). Compilation (JIT or not) becomes useful only when you need to run the same piece of code many times. At which point, you should probably move it to C++ in Haiku’s case.
To me, a “shell” language is something to use interactively or as only the very high level control structure of a program (so, a sequence of instructions that will run once, with a few conditions and maybe the occasional loop to iterate over files in a directory or so). In that context, an interpreter will do better than a JIT, because it can start running things immediately. Less memory use, and if the code is not repeated so much, it can even be faster overall.
So, don’t jump into making structuring technical choices as the first step to answer a problem. We should first agree on what is the problem we want to solve here. I don’t know what problem PowerShell is trying to solve with JIT and compiling, because for me, that’s the opposite of what I want in a shell: code that will run once to a few hundred times, and where the cost of compiling it would not be reclaimed by executing it faster.
I prefer to focus on a native shell, which is integrated with the API.
If we need POSIX support, we already have Bash, and whoever wants to use it, can use it.
If we really want to move forward, and differentiate ourselves from other operating systems (for example: any generic Linux distribution (or any other UNIX/POSIX compatible)), we have to think about projects like this.