I wanted to chime in here and say that if this shell idea does become a thing, definitely take a look at Nushell. It really takes linux shells and makes them more modern. It’s pretty cool actually, and much better functionality and syntax-wise than Powershell, imho. Although, maybe leave Nushell’s pure-functional leaning paradigm aside, lol.
I think the derivation came about when we realized that the shell is the GUI, and that you only need to create a graphical application for what the shell does. Anyway, if we can make a new terminal with access to the API.
1 Like
I was biting my tongue and wondering is anyone else would mention that. Now that the APi is at least partially mapped, you should be able to load any .Net assemblies and use them in PowerShell directly.
The shell is a program that controls other programs.
UNIX shell, and hence Haiku shell, does this on a really simple basis: flat argument list, unified I/O, boolean exit status. Programs that work on UNIX need only know how to do those things.
There have been other more sophisticated command line interfaces - VAX/VMS DCL for example - but the improvements probably weren’t worth the trouble.
Apparently someone at Be wanted to put a useful common scripting interface in the Be API, as there are vestiges of it in the graphics interface, but if any application actually makes use of it, it’s news to me. For example of what I’m talking about, you could use “hey” to invoke the web browser, tell it to connect to a site and get a file, maybe more complex interactions if you like. Someone would have write the part to receive scripting messages and execute the actions. The last I looked, all we have is twiddling with the graphic elements.
That was a feature of the Amiga operating system. Applications could set up an “ARexx port” and be interfaced via ARexx.
This is all command line stuff, which apparently some of you can’t stand, but the principle isn’t that it happens on the command line - the point is, you have a program that controls programs. That requires programs that understand how to be controlled, and beyond that you decide how it looks.
3 Likes
In current versions of AmigaOS, the Rexx scripting language has been superceded by bindings to Python on AmigaOS 4.1 and Lua on MorphOS 3.x. The only remaining vestige of ARexx (besides the ubiquitous ARexx ports for interprocess communication) is the open-source Regina on AROS. In summary, Rexx is a dead language on anything other than 68k based Amigas.
Commodore’s AmigaVision had a graphical scripting engine called FlowEditor. Had Commodore maintained their private-label contract with the company that made it, AmigaVision would have superceded ARexx.
This relates to Haiku as well. If Haiku had a graphical shell based on the ColumnListView gadget, it could just as easily supercede some text-based scripting engines. Luau looked promising as a bytecode based Lua derivative. If there were demand for it, a bytecode generator based on such a graphical scripting engine could be a good start for a next-generation shell.
1 Like
Nope. You will get nothing useful from a next generation shell, until it has a next generation environment to work in. Today, we’ve got
- the UNIX command line world, and
- a bunch of Haiku applications that have no idea about anyone using them through another program (shell.)
The UNIX command line applications are handled perfectly by the UNIX shell. The rest, Tracker.
I see a variety of complaints about the command line programs. If you want to write new versions of all the command line programs, that would be great.
Unix legacy shells won’t go away very soon. Too many legacy scripts depend on a Posix shell being around. This includes the “unholy union” of Python and Bash used by HaikuPorter.
I thought that was what this thread was a start of.
We have BeBREXX available in Haiku. I think the only place it’s used so far is ACE where I reimplemented the AREXX API that ACE uses on MorphOS. So it’s surprising to hear that it only exists on 68k Amigas.
I need to look into the Python and Lua integration someday and do a compatible implementation using BeBREXX.
And also see if integration with BeOS scripting is possible.
There is some scripting support in Tracker that does more than the basic UI things, but also it’s possible to send raw BMessages using hey, bypassing all the scripting stuff, and since a lot of apps are opensource, people have found way to exploit this by looking at sourcecode of the app they want to target.
The BeShare to IRC bridge that connects to the Haiku irc channel is done entirely that way, wiring Vision and BeShare together using hey.
1 Like
Another thing I was thinking about was a way to monkey-patch the Posix readargs() function with a macro to redirect it to call a Haiku-specific version that can trigger a GUI dialog box and make the --help option locale specific in the process. Depending on how Haiku implements readargs() it might not be necessary to monkey-patch it. Maybe BMessage and Hey is already enough.
readargs is an VmigaOS function, not a POSIX one. In POSIX you have getopt, but not all apps use that, and trying to show a GUI from there would have the following problems at least:
- that function is in libroot, nottlibbe. We don’t want libroot to depwnd on libbe
- you would need a BApplication to oe able to open a window
- changing standard posix apps to do this would probably break some existing scripts, including autoconf scripts when trying to compile software (these will test availability of some command line flags)
- the interface to getopt is much less descriptive than the one for readargs. From inside getopt you only get the option names and wether or not they take an argument. No description, no argument naming, no help message
And I’m not sure what the point is anyway of showing this in an alert this way. Just run the app with the --help option, capture stdout/stderr, and show an alert with that if you really want an alert?
Ok. As you might have expected, I was basing my idea on an Amiga utility that would intercept the template of ReadArgs and produce the parameters using input and output redirection. See Aminet - util/cli/r.lha if you want to try it on MorphOS or AmigaOS 3 with MUI.
After having given it some more thought, using an external wrapper for the GUI for each command-line utility would likely be easier. As you mentioned, the --help option would need to be totally reengineered if intercepting getopt() were to be implemented as well as other GUI funcitonality. There is already a wrapper for FFMPEG as an external add-on, I think.
What do people need to do in the shell that they can’t do using the Tracker/Applications, besides chaining applications together?
Chaining applications together, accepting parameters as output, passing parameters in, manipulating and storing parameters, looping and branching based on parameters… Basically a shell is a programming language for dealing with program launching, environment variables and lots of glue code.
Is all of that done with plain text? Are there any mime/filetypes involved?
EDIT: Silly me, these are the shell scripts you are talking about…of course they are plain text.
Thus bringing us back to the subject of: “What should a next-generation shell look like?” I think there should be a bytecode somewhere, higher level than WebAssembly (which is deliberately kept only a step above real Assembly) but lower level than an interpreter.
I ported Luau for this purpose but Python also caches its parsing with bytecode. Another thing I liked about Luau was that it supports full binary compilation on late model x86_64 and ARM64 also. The interpreter runs as fast from bytecode as LuaJIT does from its JIT, even without the binary code generator. All that’s holding it back is upstream bugfixes being needed and support for older systems.
Can we agree on the bytecode level abstraction at least?
Look at how much of the computer’s resources go into interpreting shell scripts. Practically speaking, it’s immaterial, isn’t it? The only advantage a compiled program might have in this context, is upgrade independence - less breakage just because the interpreter was upgraded.
Find a real problem; solve that.
But why on earth, why!?
3 Likes
Here we all are speaking English and thinking that’s perfectly normal. Maybe it is. In some other part of the world they speak a much more logical language and see this script based on English and think: English sucks! I would like to hold out for the possibility that we can do better than English when it comes to programming and scripting languages.
1 Like
So you mean a multi language level ontop of the shell “engine”? But that makes sharing shell “recipes” a bit difficult, or?
Or do you mean we should invent a sort of advanced syntax which is more complex than English? That would be counter-productive.
High-level bytecodes are storage for constructs that can be rendered as text or graphical language. 'Nuff said?