I like your linked article even though it was just a mockup in 2011. I personally would have preferred native widgets instead of a WebView but if we need remote access like the author seemed to, a web-view with native widget bindings would be ideal. Since it runs on Node.js, it will have an optional JavaScript JIT also. That only leaves the question of “Is there anything in this article that hasn’t aged well?”
For a Haiku based implementation, what about:
Each command returns a BView that can be added to the window. For simple commands it will be a BStringView with the result. But it could be a more complex thing with images, buttonr, whatever.
It could be made to look like a chat app at start, with your requests and the replies clearly separated in chat bubbles or similar. I imagine there would be an “help” command, that would reply with a tree view of possible commands, which you can click for more details.
It could have legacy support for running executables from the path, but maybe some things would rather be done as add-ons
5 Likes
That sounds good for an interactive window. How about scripts?
I think a structured hierarchy of indentions could be represented by a tree gadget of commands with multiline block comments as the optional first entry per indention level. The collapse/expand buttons would act as a Scintilla-style fold indicator.
One of the things I liked about the TermView article was the way that autocomplete was integrated everywhere. Another was the way that commands were tokens rather than text.
Speaking of tokenization, does a shell script need Git support for version control? We’ll need to have a text representable save format rather than (or in addition to) a flattened structure serializer if so.
Of course.
Also, this is our opportunity to make a good scripting language, adapted to our needs.
It doesn’t need to be turing-complete. A domain-specific language (DSL) should be enough.
We can take advantage of this restriction to provide security guarantees and more powerful tools.
My idea of such a language might be something like YAML + flow control.
That may seem too restrictive, but it’s not really a problem: all the libraries and executables in Haiku are compiled, they just work. So there is no need to use a JIT or AOT shell.
The shell is just a small interpreter written in C++.
This language could be used as scripts, or as configuration files.
If it’s object-oriented C++, a more complete language can inherit from the scripting engine and provide additional features. As long as it can execute programs, query and generate attributes, do structured flow control and do interprocess communication using a “hey” command derivative, will that be a good start?
Looks interesting, yes.
Alright. Let’s consider that a minimum viable product.
As for @extrowerk ‘s “hash” name, it’s a little too close to Linux’ Bourne Again SHell name and in addition to that, it’s too difficult to pronounce the name difference in a way you can hear in a noisy convention hall. Also, it sounds like a utility for unordered maps in C++. 
If the Inc. doesn’t object to the direct use of the trademarked name, (and considering it’s system specific to Haiku, there should be no objections) I propose we have “Haiku Shell” as the name. Likewise the MIT license is the main one Haiku uses.
Once the name is agreed to and the general requirements are set, I can set up a GitHub organization. As much as I dislike Microsoft and its meddling A.I., those organizational kanban charts integrate well with team structures and a separate issue tracker and discussion boards make a deal that’s too good to pass up. As long as nothing needs to be secret…
What exactly do you mean?
I’ve always wondered why Haiku still uses the plain old Bash shell as default and not something more user-friendly like Fish,that I’ve been using on the BSDs for many years now.
TermKit looks even more promising to me,if done using native widgets.
I don’t want that even the Terminal turns into bloated Electron bullshit or something like that.
Forgetting about that for a second,TermKit otherwise looks like what a native Shell for Haiku should be: Supporting for non-power-users and simplified to make it fun and easy to work with.
I’ll closely follow that project and I’m very interested what you’ll create.
Maybe just rethink if that really needs to involve Micro$oft again 
Codeberg.org and the Forgejo software also supports Kanban boards for organizations and has issue trackers and that all,without AI nonsense and selling your soul to the devil and all that.
4 Likes
The bourne shell, and the TTY emulation layer simply need to die.
To emphasize this i have a long list of stuff that makes this, in my opionion, hard to use or error prone which I will highlight in it’s entirety below : )
edit: think i have more but my pc froze, and i won’t type this on my phone…
No structured formats
→ requires escape sequences (sometimes even three times, for the shell, some programm that interprets them, etc)
→ can’t differenciaate between “arguments”, “paramaters” leading to unfortunate side effects of the file “-rf” not beeing deletable unless you know the arcan invokation of “–”
→ every tool has a different syntax, dd for example, or find vs say, egrep
→ tools autodetect if you are “interactive” and wildly change their output which means there is no way to reproduce some behaviour or save it non-interactively, additional info like colors gets lost in logs
→ no way to ahead of time know what parameters will be accepted in what context (apart from “read manpage”, which is very confusing with large tools)
→ no way to properly differentiate STDERR from STDOUT when inspecting a log later,
either you loose the information what was which OR you loose the information of which log line was send after which one
→ autocompleting is hard and only accomplished heuristically, and the shell does not help at all (for example, having a “field” you can type into for different stuff, making it unescapably clear what belongs to what)
→ path names are often relative and can’t be reused in another context (that is, you the user know which path it was reffering to, but as soon as the PWD changes the computer no longer has any clue, the haiku terminal cannot differentiate anymore)
In addition to this:
→ no way for a binary to easily define additionall names that it can be called with, to expense with the need to have one binary that accepts 12 different flags to behave as different programms with the complexity that comes with that
No, we should move away from “text format” for reasons outlined above.
In addition I’m bewildered why you care what the name is now (seems an irrelevant afterthought) or why you want to setup a github org now, ugh.
We literally already have a forum here, and gerrit, and a bugtracker.
I’ve thought about designs for this possible shell for years, but i refuse to be part in any github setups to make it.
4 Likes
I’ve got an account there too. Maybe I should try it out! Last I checked it didn’t but it’s been a long time ago.
@Androsio
I mean the shell can be a building block to bigger programming environments. Object-oriented programming is extendable. I started looking into a visual programming language some time ago and never quite got anywhere. It was an idea that came up in this thread: Any wheels that need to be redesigned?
2 Likes
The issue I discovered years ago was when I was wanting to compile C# code from the regular PowerShell, which did not have access to the compiler. After a web search on the subject, I had to launch into a different shell to get access to the compiler. It’s ridiculous IMHO.
I’m starting the project on Codeberg as requested. See HaikuShellDev - Codeberg.org for details. @nipos I may need you to co-administrate this because I’m less familiar with Codeberg than GitHub. Also, I will need other people there to join up if intetested.
1 Like
I have been reading this thread daily…
I’m an IT professional that came from the UNIX world–so bash (or other shells) still manage the big OS’es just fine; as well as, all the Linux OS’es. Never used Fish–so I cannot comment about that. I work in SUSE and Windows shop now and for my M$ daily stuff Command Prompt does most of everything I need to manage the systems or databases now. I use Powershell when CP cannot accomplish coded complex tasks that CP cannot do (simply because M$ chose not to develop features for CP and focused only in Powershell).
Since I do not anticipate seeing the Haiku as a corporate OS anytime soon–though I can dream about it. So developing a new developer’s shell would not be used by the daily average Haiku user. There is no real need to do so from this perspective.
As long as bash stays available in Haiku–that is all I need for the future. All my shell scripts will continue work now and for tomorrow. plus bash is very easy for first-time users to learn as compared to Powershell or complex shells that have a steeper learning curve.
bash is ubiquitous for a good reason–it is a good standard.
I really have enjoyed this discourse guys!! Keep going…some very good ideas…
2 Likes
I like that idea very much.
In fact, I had been exploring that line of thinking.
Nowadays, people who start programming often use Bash or Python. Nobody starts programming with Perl or Ruby.
Perhaps a scripting language can be designed that is similar and compatible with C++. Think of it as a “C++Script”.
That “simplified C++” would be a good entry point to new programmers.
I know how intimidating C++ can be to new programmers, even those who already program in other languages, such as Python.
This is the time to create a “simplified C++ for the Haiku shell”, it would offer the opportunity for new programmers to try to dive into C++ and create native applications. The learning curve would be less steep. And programmers who already know C++, would have no problem using the shell language, as they would feel more comfortable.
And if done right, this new shell language could be used in the future to rewrite system applications that are currently written in other languages, such as Bash or Python, and make them “native”.
1 Like
One reason my first attempt at making a visual language failed was that expressions were stored as parse trees and required a complex “formula editor” that ran in its own dialog box. Too many dialog boxes could happen at once.
My suspicion, at present, is that separating identifiers by primitive return type will simplify heuristics required to do intellisense-style autocompletion, while eliminating irrelevant options.
The current proposal is a YAML derivative with flow-control. I don’t like using XML nor JSON to build on but parsers exist in general states for using them. I’d love to use a binary encoding but there are a few hold-out issues:
-
Git chokes on binary files so version control becomes problematic if we can’t serialize our scripts to text.
-
Editors become difficult to debug when you have to examine the files for corruption in a hex editor.
As version control technology improves, we can phase out text-based formats into compact binary and simplify instances of Scintilla into native GUI editors.
Simplifying C++?
@Androsio , this is why I proposed using a Haiku-specific feature called “translators” for the parser infrastructure. It would allow other code sources to be imported into the shell-derived editor expansion that implements the programming paradigm it uses.
The first time I proposed such a design, it was stapled to the back of a résumé at Amiga, Inc. once it was bought out by Gateway 2000, Inc. in 1998. I wanted to use the datatype features of AmigaOS 3.1 to be used to provide a coherent compiler infrastructure with a binary bytecode.
Since then, the technology to implement such a thing has reemerged in different places. BeOS had translators similar to Amiga’s datatypes back then but Be, Inc. was struggling to survive in 1998. Once Bill Gates personally forced Gateway Computer to exercise a monopolistic and illegal non-compete clause embedded in its Windows OEM license, Amiga was spun-off as an independent company and it started struggling the same as Be, Inc. For all I know, I may be on an equally illegal blacklist by Microsoft and its suppliers for my role in trying to cement opposition to their company!
TL; DR
I’ve been at this struggle a long time. It would be a shame if it failed now. I just think it may be too late. I refuse to give up nonetheless.
IIRC, in the past there was a link to show hidden messages like this one. This was removed accidentally during the last forum upgrade?
3 Likes
why???
Yet another service to register to?
We still have a proper code review tool, a bug tracker, a forum for haiku. For Haiku! Not haikuports, haikuarchives or any third party site. why would you try to make a third party project to implement this OS level shell? Unless your goal is to not let the haiku developers review it…?
Why would I design a syntax that programms use to talk to each other to fit into git?
“Just text files” are just binary files too. Just an annoying hard to parse format that means thousands of different things, it really is the worst option we could pick, Haiku usually does things “right” not “fast”, so i’d definetely avoid this at all costs.
Above you talked about a minimum viable product, now you talk about doing it the wrong way first and later phasing it out. what’s up with that? why would we design our software in such a way like google would? They use all these techniques to try and make money fast, and even then they fail. Let’s just do it right instead of fast, in the long run you will have much less cost or maintenance effort.
Why is it in scope for this new haiku specific shell to consume everything using translators? Would it not make way more sense to properly design this and add support for executables as we please? If you need python use python, and if you need “legacy” shell scripts use shell scripts. nothing much to it.
I think some of your claims are a bit exagerated.
No, it’s just dd. All others use quite standardized POSIX syntax.
From my experience it is always possible to get the same behavior with some explicit options. So “there is no way” is exagerated
This is plain wrong, you can use symlinks and the binary will know which name it is called by by looking at argv[0]. This is how busybox on Linux works, for example.
I generally agree with what you’re saying, but there’s no need to make things look worse than they really are.
This is better started as a 3rd party work. I don’t see why it should be included in Haiku main repo from the start.
I am not going to use something that stores sourcecode files as binary. Git is not really a problem, it can handle it, but you need tools like “diff”, you want to be able to copy and paste code from one project to another (or move it from one file to another) easily, …
This is all easier with a text-based format. Which does not mean you have to do all the editing in a text editor. You can have a graphical editor that loads and save files in a text based format.
By the way, since a project like this should start with a review of already existing options, let’s add this to the list of already existing options:
http://www.goodeveca.net/beos/streamweaver.html
1 Like
I assume “all others” refers to posix tools specifically? otherwise there are severall types I know off (add to that that “–” is only supported by some tools, not all. posix for example sais cat has no options, but cat has options, so it doesn’t always support --)
single letter options
single letter options with parameters
double dash options with parameters
double dash options without paramers
option=value
etc.
I should have written no automated, tool-agnostic way.
Yes, that is true. But that is what I ment with easily, busybox does this but not even it makes them per default, the installation instructions put the responsibility for this to you, the user to set this up. It’s not easily accomplished and as a user i don’t have any way to know beforehand which names are supported besides looking at the documentation.
(edit: busybox actually does expose this info, but it is again a tool specific option for which no general solution exists)
What do you mean with sourcecode in this context, the scripts themselves or the api applications talk to each other?
It’s perfectly possible to have a diff application for non-text files, in some cases this could work even better than diff on text files.
I suppose text files could be used with length based parameters too, that is, instead of escaping specifying “the next option is 32 bytes long”. This would eliminate escaping while staying with a text file but make this harder to read/edit for a human.
Using yet another set of tools makes getting input from other developers that much harder.