A few days ago I was looking for a PowerShell manual, and among its features, I read that it accepts and returns .NET objects.
Haiku is written in C++ and has an object-oriented API, so would it be interesting to have a native shell, which can interact with the API objects directly?
An automation solution consisting of a command line shell, a scripting language and a configuration management framework.
Yab has interactions with the GUI but is neither object-oriented nor JIT compiled. I tried writing a transpiler for it but BASIC syntax is quite foreign to C++ developers.
As for PowerShell, it was designed to take advantage of .NET’s JIT and runtimes specifically. IMO, .NET is overbuilt but good otherwise. The same goes for Java.
There is an effort underway to make Python bindings for system APIs. That’d be good enough for most purposes. What would we need beyond that?
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.
A single tool to control everything.
The bindings to other languages are far less effort in the long run.
I propose the “hash” name for this, the HAiku SHell.
What about xonsh, with the python bindings?
Would it follow Bash syntax or even be Posix in style? If we are even going to consider such a thing, we should list specific requirements first.
Does this sound good for starters? I had my doubts at first but a scripting engine that could leverage translators might be worthwhile.
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”.
Why would you ever need such a complex and performance focused design for an OS shelll?
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.
@nephele
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.
That’s one of the things about Windows and its variation of shells and their supported modes that drives me nuts.
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?)
Sorry for the OT reply of course 
The initial comparison was with PowerShell which is huge and requires the use of the .NET framework’s JIT. A shell prompt shouldn’t need the features of PowerShell for an interactive environment.
Another comparison was the need of bindings to other scripting languages like Python. Python also has a bytecode and a JIT. Some Python spin-offs can even statically compile to a native executable.
A native shell designed to replace either of the previously mentioned designs should be in the same league.
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.
Ok, so reusable code should not be a thing? Will Bash still be with us? Bash is required for Posix, mostly and can’t go away without breaking changes elsewhere.
Haiku will boot just fine if you uninstall bash. So if you don’t want it, from the OS point of view, you can remove it. Some other packages will probably not be happy about it.
This has already been discussed many times. You only have to see Please make a new software for Haiku, not only a port to know what I mean.
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.
I like the idea but the definitions need to be specified. Will GUI apps be allowed in the Haiku shell? If so, how will they be implemented?