Is SQLite3 completely necessary?
Could it be replaced by something else?
I’m thinking in that direction because it could easily be upgraded to allow collaboration online by putting the file manipulation onto a SQL based server, as was done for Drakon.
Collaboration tools coupled with replica sets of servers and in case of heavy loads, sharding of database repos, make for a better user experience if done right. It might even bypass the need for local version control tools. Thinking ahead, that doesn’t sound so great.
Maybe the best solution toward a cohesive scripting experience is to give the common tasks a graphical user interface. That way the staring at a blinking cursor as you try to remeber the name of a cryptic command syndrome will be remedied.
I like that.
Do you have any “mental prototypes” about it?
I was hoping to make a graphical programming and scripting engine but the one problem staring me in the face about it is that version control and file differencing is difficult in graphical languages.
Yes, but that does not mean “blindly use attributes for everything”. And especially attempting to fit an existing app that was designed and tested with sqlite to work with another quite different engine and storage seems like a bad idea.
If you are designing an application for Haiku, you can think about what is useful to expose to other apps as attributes, what is convenient to store there rather than in the file body, etc. But, you can’t take an app that was designed with a completely different model in mind, force it to store its data as attributes, and call it a day.
4 Likes
OK. What if I exported a file type and file type version as attributes in a file based on SQLite? Would the Haiku Filetypes utility be able to track it then?
Don’t know what the conversation drifted to, but replying to the original message: Would it be easier to just… use PowerShell and then load Haiku API .dlls and then interact with those objects?
1 Like
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.