Native shell?

Feedback Ideas
183

After three days of pause, and reading the 30 messages I had left, I’ve caught up.

I have been thinking about all this, and I think there are problems that still have no solution. Those solutions (in many cases) is not creating new tools, but modifying something existing.

Following @PeterW line of thought I would also like to differentiate between text shell (terminal) and graphical shell (GUI).

The original BeOS was designed with GUI from the beginning. Haiku the same.

The system can be completely controlled with a GUI. Just not all those functions have been implemented yet.

Earlier in this thread, recursive file handling, or parameterized searches have been mentioned.

Perhaps the solution is not to create a new tool to “plug the hole” of those missing functions. Maybe the solution is to create BeFS 2, with database capabilities, to provide solutions to all these problems. And re-create the GUI so that the pop-up menus have those file manipulation functions.

The above was just an example, but it clearly shows the line of work we should follow.

Hell, I would learn C++ at an advanced level just to create BeFS 2.

For those who still want to use a text shell (terminal), possibly, that future scripting language we have been talking about, will look like SQL. It would be the perfect complement to the hypothetical BeFS 2.

For those who want to create graphical applications, but are not programmers, we have ALE (which crashes too fast) and BeBuilder in the repository.

Even if we wanted to have one more tool to create a GUI, we could look at Kexi (it is the free equivalent of Oracle Forms).

Following that graphical programming line of thinking, there are many visual languages, such as Drakon, Flowcode, or PureData.

For the more hardcore programmers, we still have C++.

3 Likes
184

Does the glass elevator article cover the possibilities well enough to be a starting point for BeFS2?

1 Like
185

Many of the concepts mentioned in the glass elevator have already been mentioned in this thread.

That means that the glass elevator is a very good starting point.

Just combine the ideas from this thread with the glass elevator and we could start creating the first sketch.

186

Just adding this to the list of existing things to look at:

https://www.marceltheshell.org

It uses Python and provides an UNIX shell like pipe approach to chain things together, but instead of text streams, it’s Python objects.

4 Likes
187

OK, this - marcel - looks like an example of rewriting the UNIX/Haiku command line applications. In the example I’m looking at, “ps” pipes a Python object - which obviously has tremendous advantages, but means you’re rewriting “ps”. And everything else. A big job, and what I’d call this is a new OS, not a new shell.

You could get 90% of the advantage by rewriting a few of the worst offenders - ps, df, etc. - to support user specified output formats. (NB last I looked, Haiku’s ps doesn’t have enough going on to be worth the trouble anyway.)

For those who are still in it for a shell, that has some kind of alternative UI, may I suggest that instead of “byte code”, you just generate plain UNIX shell. Then you don’t have to sweat about getting all the UNIX shell stuff right, which I guarantee you is harder than you think. For one thing, a shell with an exploit problem is big trouble.

For those who just want a more language-y shell, there are some alternatives to the Bourne shell that never went much of anywhere but have a little more elegance. There’s “rc” from Plan 9, where the syntax is a lot more bearable and there’s a formal list data structure.

And a related project “es” that was pretty cool but might be harder to build right off on Haiku - if I remember right, it used an old garbage collection package that isn’t real portable. It was kind of similar to Lisp - not the parentheses, it looked more or less like any old command line, but it had dynamic and lexical scope, stuff like that.

188

Marcel the Shell

I like the looks of Marcel. Plus the fact it’s written in Python saves time and is much more portable than just about any C++ based framework out there, Posix or otherwise. If it uses Python’s JIT internally and uses the Python bindings of the Haiku APIs, it looks like adding it to HaikuPorts would be slam-dunk easy.

@donn
Python can wrap calls to binary command-line executables without too much pain. The only time we’d need to rewrite in Python is to generate a structure around it.

189

For me, Python would be a wretched choice. It’s not that I hate the language - as far as I know, my BeOS API Python library is still the only one that has made it out of the laboratory - but a basic problem with Python applications is that they are specific to a certain interpreter version, and they don’t care if they break your application in the next. Your only defense is to incorporate the interpreter and library modules into the application itself - I’m not making that up, it’s what they were telling me. But you can’t afford to do that with every “script”, I think. So wouldn’t every pneuShell “script” be subject to potential breakage depending on the version of the interpreter?

You might also test the startup resources for a “hello world” python program, and consider that shell scripts sometimes run rather often.

I’ve certainly used it to exec external commands. What I’m telling you is that there’s more to a shell, than just forking and execing a command. You might consider how bash has evolved over the last 30 years, and if there have been any serious bugs along the way. (There have.) Let bash do that part of the job - it’s going to be faster, and safer.

190

The fact that this conversation has stretched on as long as it has is proof that Bash doesn’t cut it. It is utterly insufficient for the task of being a graphical environment’s scripting element.

I can accept that Python has its shortcomings. I started my port of Luau because Lua has similar difficulties and inefficiencies.

I cannot accept that Bash is all we need. I sternly and adamately refuse! Bash is going nowhere and I mean that in the most disparaging way possible. Its syntax is cryptic, its not beginner-friendly. Trying to fix Bash is putting lipstick on a pig.

5 Likes
191

Go ahead and make something wonderful that you think will be useful. I’m just saying that you’d do better to make the wonderful thing write bash rather than bytecode.

Though from the way you’re talking, you might be better off learning the Bourne shell, i.e. bash. It’s a large part of the reason half a century later we’re still looking at a UNIX style environment. It’s “going nowhere” because it got there. As I mentioned, there are shells with more elegant syntax, but the motivation to go there has apparently been pretty slender over the 30 years or so they’ve been around.

192

You can’t make a new shell on linux and have it adopted because of the fragmentation that linux has. We on the other hand could make one. bash still beeing used has nothung to do with it’s quality.

7 Likes
193

My hope is that whatever we do work on, is functionally orthogonal to bash. The bytecode is a way of making compact, fast scripting in a native language with rock-solid performance and type/error checking on-the-fly as a feature, among other benefits. However, nothing is prohibiting a compiler backend from emitting bash code and remaining entirely compatible with bash’s own features and functions.

There has been whine about bash being unapproachable, obtuse and confusing; while praise about it being particularly streamlined for the common administrative tasks - processes and jobs, files and users.

There are also other languages that compile to, or wrap around, bash - some examples are in the answers on this stackoverflow question.

Plumbum is reminiscent of the earlier Marcel example, again in Python, except this time, more “shell in python” than “python in shell”.

Also, keep in mind that we want to work on a principle of least surprise here - A skilled command wizard could hide away the panels and simplify the “coding block” UX to being little more than rich syntax highlighting; the code is entered by keyboard, and you’d never see “bytecode” manifest itself.

I feel that a robust metalanguage, whatever we do decide to work with, would go wonders to making automation and scripting accessible to both skillful systems-administrators and users with bright ideas and a tenuous grasp on the efficacies of programming.

Also, I’d like to note a particularly good example, in terms of in-interpreter documentation: The QBASIC Help system. Pressing F1 with the cursor on any keyword, drops down a window with documentation about that keyword - what it does, how to use it, relevant examples. (Microsoft made many programmers out of ordinary people, by embracing strong documentation; despite the other two E’s of “Embrace; Extend; Extinguish” having a less positive impact on the state of programming overall.)

We don’t want to gatekeep scripting to an elite force of man-page grokkers and JAPHs with six mile beards; we want to have our shell “uniquely Be” Haiku, so to speak. We’re not a UNIX, we’re not Linux; POSIX compatibility is a feature, not a function, of Haiku. (edit: see below) Though I argue we shouldn’t interfere with POSIX compatibility (yes, this means we keep Bash or zsh), Haiku is still running without it, or other UNIX/Linux staples like X11 or Dbus or hier(7) adherence, and so on.

We put the ‘start menu’ on the top right of the screen; quirky, user-friendly changes to break from “tradition” or “UNIX” are not going to hurt us, especially if it’s not exclusive against existing terminal-based shells and UI.

Really, one big change we could make, with a Be/Haiku API-connected shell, is in accessibility - to allow people on limited input or output, such as braille TTYs, to interface with otherwise GUI applications, because they follow a robust UI API with a navigable widget/window hierarchy.

(I will note - Haiku is, for all intents and purposes, a UNIX system. We don’t need to relitigate that; however, it is unique in that it breaks from tradition in compatible, but unique ways.)

3 Likes
194

I think this is a mistake, a new scripting language should not compile, especially not to bash.
We should not use the posix commands, as their text syntax is a major source or problems.
bash and the posix tools will remain an option to install, if you really want it. But this new interface should replace it, not be a superset of it.

I’ve not followed the last messages in this thread but I am massively confused why bytecode has been thrown in again after beeing dismissed above already.

Using python is a major mistake, as is lua. I love lua but it is unsuited for this task.

Please let’s rather design a proper interface that the library routines (that’s what busybox’s multicall basicall ammounts to) use to exchange data, formulate an ordered syntax to set up these “commands” in tandem with the “easy” gui (with the gui beeing a first class citizen)

IMG_6559
IMG_65591425×458 56.1 KB

(xkcd: tar)

2 Likes
195

One person dismissed the idea re: bytecode. If I stopped doing things because one person told me to, I’d starve.

I’m a lot more conservative to the meaning of “bytecode” here - I’m not looking for “what if java classfiles” or “maybe LLVM” here. I’d go for an AST or tokenized binary representation that maps to the command entry language, so as to allow it to be transformed - to text, to native code, to bash or python - without an intermediate parser step. That it controls a state machine, sequencing programmed instructions (as is the case with any shell language, interpreted or otherwise - even Bash works in this way) makes it a bytecode and the interpreter a virtual machine. Not the other way around.

Otherwise, I completely agree; a semantically sound UI, graphical or otherwise, goes a long way to defining the shape of the program.

(And the GUI should be first-class, but the shell should be accessible from a traditional, VT100-compatible terminal emulator, as I mentioned.)

196

It should not.

VT100 terminal emulators need to die.

There is little point in creating a new interface for this if it is constrained to legacy interfaces that serve no purpose anymore.
We don’t use terminals and we shan’t emulate them.

“because one perspn said so” makes little sense, pulkomandy explained above why it makes no sense, just ignoring that is silly. It’s much better to have a discussion about it.

Compiling to other languages is possible, but so is transpiling. It should not be a goal at all.
Shell scripts are fast because the interpreter starts fast, the majority if work in a shell script is done by the individual library routines, applets, commands etc. NOT the interpreter. Optimizing for a more efficient interpreter or compiler makes little sense if most time simply isn’t spend on it (and most inefficiencies are because of bash’s syntax, not because if any interpreter.

With a properly designed interface transpiling to bash would also be impossible because the “just use the exit code and argv and read pipe 1 and 2 for text” interface would not be used. And that is basically the only thing bash understands unless you build a command that knows the proper way.

Honestly, just leave bash and VT out of it, those are the parts that need to go… we don’t need a transpiler just so we can keep bash.

2 Likes
197

It’s prolly still a good idea to have some form of backwards compatibility though in some form, even if just for a certain transitory period. People should be given time to migrate their scripts, HaikuPorts included.

1 Like
198

You guys are just going to have to each go your own way, and see if you can make something useful, because there isn’t any common basis for what you’re trying to accomplish.

I mean, what’s the real problem? People can’t write shell scripts, because the shell is hard? Come on. I’m telling you, there are better shells - and they go nowhere, because as wacky as the Bourne shell is, it isn’t a big problem - but if you want, give it a try, “rc” will build on Haiku. If you want a programmatic interface to the UNIX command line environment with the hundreds of /bin commands provided by Haiku, you aren’t going to do much better than rc, and no one will care anyway.

You hate Terminal - and you’re going to come up with some kind of graphic programming interface? That’s a terrible pit to dive into, in my opinion, but it’s your spare time, not mine.

You hate the UNIX/Haiku command line commands? Yeah, that’s some funky stuff. Some of them maybe could have a graphic UI, like tar mentioned above - because it’s just command line, there isn’t any issue with the output, except that you will routinely want to do tricks with the I/O, current directory etc., and maybe your graphic UI will fit in there. But a lot of the funk in other commands is what comes out, and you’re going out into a lot deeper water if you try to wrap that stuff, or rewrite it. What’s the direction here?

Unless two of you have the same idea about where you’re going at this level, there’s no point in discussing implementation details.

199

TBF, I don’t see the point of replacing the Unix shell, we are going to need it some way or the other. What would really be interesting is an Haiku-specific interactive text based console, that allows macOS Automator like workflows with on-device pattern and use recognition that would actively guide and assist the user. Kind of an interactive personal assistant. It would have deep integration with the system like hey, but much more user friendly and with a pretty user interface with auto-completion and guidance.

1 Like
200

I have identified two ideas/projects directly: a new terminal, with access to BeAPI, and a new scripting language. Both ideas are complementary.

Tangentially, I have identified a visual programming language, to be used with the new terminal and the complementary new scripting language.

201

No, not with a long-enough transition period for migration. Long-term, a goal should be that the traditional Unix terminal should no longer be needed on Haiku specifically. Its features and capabilities are all possible with whatever the native shell becomes and so much more beyond it.

2 Likes
202

IMHO this is true. You can have POSIX tools and people will appreciate it. POSIX/Unix is better than some people say. But the true advantages and the true essence/style of Haiku is very different from POSIX. Elegant and graphical and with a mostly simpler UI. So should be the next-level shell for Haiku. So no bash I think.

There are many different ideas in this thread. That’s good. But this makes designing a bit difficult. So I would suggest splitting the solution(s) into parts.

1 Like