Rexx is a scripting language what you can find in Depot as well - at least it was available last time I was paging for stuff I was curious about.
1 Like
Ok, âshellâ can mean UI. For example in Windows the shell and the explorer are one and the same program.
But I think most people here will agree that with âshellâ we mean the command line (with two uses: interactive with prompt and for scripts).
1 Like
I think itâs important to define what we mean by a âshellâ, a âconsoleâ, and a âterminalâ.
A console is an interface by which one works with the computer. For equivalents on Windows: The local desktop is a console; Microsoft Management Console is a console in the Windows Desktop; Hyper-V Manager is a console in Microsoft Management Console.
A terminal is an interface by which serial data, usually text, is received and generated. A VT-100 is a terminal, an IBM 3270 is a terminal, as is a terminal emulator, the Windows Terminal, KDE Konsole and Xterm.
A shell is an interface by which the programming of the machine (machine language monitor, BASIC ROM, C compiler, API) is abstracted from the user, by way of manipulating objects or commands.
The key here is that all three of them are part of a user interface. A shell can run on/to a terminal to present a console to work at.
In our case, the shell is what weâre working on defining here.
Also, shell scripting is the same, logically speaking, as UI automation. Youâre executing a series of control operations on the shell and/or to other jobs which do the same.
1 Like
I just stumbled over nushell ( https://www.nushell.sh/ ) which claims to borrow ideas from âtraditional shells like bash, object based shells like PowerShell, gradually typed languages like TypeScript, functional programming, systems programmingâ (original quote).
Maybe that is interesting?
I feel like anything short of outright revolutionary, in terms of shells, will land us with yet another âincompatible Bash-like with Featuresâ, like zsh, fish, dash, and others before it. Nu seems a lot like that - just a bunch of sugar on top of a shell, things one could probably dotfile or oh-my-* another shell into being.
That is to say - if weâre not going to do something profoundly different than bash, we should instead work on the bash we already have.
I say, instead, we should set out to do something entirely ours. And, while terminal/vt100/tty serial buffer compatibility is a nice-to-have, it shouldnât be the defining feature of the shell, it shouldnât be the mandatory interface. We have a GUI, we should use it.
3 Likes
I also do not know PDP machines as they were mini computers âŚ
I was birth in in the beginning of '70s, so I could join in the microcomputer and home computers era in the '80s and '90s of prev. century/millenium - so no personal experience with them.
However Kernighan and Pike started to work language C and UNIX OS just for a PDP-11 machine - the PDP is sure the model is not. I was read their book about it in 1990 or 1991.
Then I was fan of UNIX after I finished the book. It was after I met with DOS in school lab on one machine only, and after I saw a Win 3.1 at a buddy.
Until then I âsocializedâ on home computers with BASIC.
So for me a computer was always a command prompt.
That is hard to understand nowadays guys. This way a mess for them character based interaction ⌠they just want to click or hit a button and urge the developers to develop their needs.
They could script it ⌠get it by their efforts ⌠BUT : that is
HARD WORK !
They want to get ALL finished/polished - with yet another word : COMPLETELY tailored for them.
If they are not served out (immediately), then they unchain their hatred, open their pitty-pat bag and throw the all uglyness broadcasting their frustration as everything is SH1T as cry with Nero (the caesar) : ⌠Burn their ROME* !.. to the ground
*Here, ROME can be substituted with their stuff - related their ârequestedâ what should DO, how should DO âŚ
But if you carefully observed it - they would never involve themselves in the development process actively. They just anticipate - massively - aka expect it : for yesterday. It is too late for even now.
Something we could do thatâs a bit less ambitious is replace bash with zsh as it has more features and a âbetterâ license: Modified 3-clause BSD as opposed to GPL, but thatâs not really what OP had in mind.
I would like to see graphical elements incorporated into the shell i.e. GitHub - atanunq/viu: Terminal image viewer with native support for iTerm and Kitty using vixels or similar. Sure it would break text based terminals and wouldnât work on over a remote ssh session, but Iâm ok with that, and I like to see pretty pictures and animations.
Neat idea, but a lot of work.
3 Likes
zsh might be a goal for replacing bash in the shorter-term, I wouldnât mind it.
As for âvixelsâ or âsixelsâ or whatever other hacks: I donât like that one bit.
If weâre going to have the shell output to a vt-tty compatible serial terminal, it should respect ASCII and basic control/escape sequences, and not depend on slow, inefficient, and potentially incompatible terminal extensions.
An image - especially color - drawn in sixel escapes is significantly larger in memory than a plain binary bitmap of the same size, colors and resolution.
That said; Iâm for a visual and rich shell outside of a VT100-like terminal, where hacks arenât necessary to make graphics and text work side-by-side.
1 Like
What about taking inspiration from Terminology? Its various features donât require sixels or anything that could break most terminal applications.
Sorry, but Explorer is just one aspect of the graphicall shell. And the shell is not a one and only program.
Just as cmd.exe is one and only program, but to be able to use the program basically - it will start in a window that is another program which draws it, also part of the shell, when you save or load a data file that is also a different part of the shell. They would be stored/called in case Windows - using the shared program libraries - and you may know them as DLLs.
As it would be waste of disk space if such services would part of the applications - every apps uniquely - which are common in them and part of the OS services anyway.
But I do not want to precise you and make anyone else boring death who are knowing such elementary stuff better than me and finally I will be lectured for a capital stupidity I left written here and there ⌠for what they send me captain Picardâs iconic picture as he hold his bald head with their bare hands (as most famous Facepalm).
Why replace one user-unfriendly expert-only shell with another?
Getting rid of Bash is a good idea,as itâs really not the Haiku way of doing things.
But I would replace it with one of the alternatives that supports new users by giving suggestions,highlighting if commands exist or not and similar stuff.
What I mean is something like Fish or Nushell.
When I first tried to use Fish on Haiku,it was broken,but that was more than a year ago and maybe itâs working now?
Fish has been me preferred shell on FreeBSD and Solaris for years now,and itâs always awful to have to use Bash again on Haiku.
Nushell looks even more user-friendly from what I see on their website with their table-like displaying of data and error messages that actually explain what went wrong.
I personally donât have experience with Nushell yet,but it may be a good fit for Haiku as well.
Edit: Itâs a shame that theyâre rewriting Fish in Rust now 
Would have been a great candidate for deep integration with the OS,being written in C++.
But how does a visual shell fit into scripting?
And what is so good about a shell displaying pictures anyway?
2 Likes
Having used Terminology in the past, it is very useful to have even small image thumbnails in a terminal for batch conversions of media as a practical example. Also hovering a mouse over a media file in a directory list to preview it is rather useful, especially in folders where graphical file managers may choke due to large numbers of media files.
With regards to designing a native shell (and perhaps improvements to the terminal), important consideration should be made for non-programmers who may have usecases better served by a shell and terminal but have no clue how to use them.
1 Like
Struggling with the zip command the other day made me long for something like Commando from A/UX, and Iâm no stranger to the command line. We just need to build a GUI builder and feed the shell commands into it. I can only imagine the beast of a UI that the ffmpeg command would result in. Luckily the zip command doesnât replace your input files with an empty zip file if you get the parameter order wrong like tar does. Unfortunately, using the zip command only showed me the error that Zip-O-Matic wouldnât: Out of memory, so back to the drawing board on that one.
2 Likes
Not sure how Commando in A/UX worked, but perhaps finding a way to build a GUI from parsing man pages would be a good direction to go in for recreating it at scale?
Iâm not a fan of âitâs a shell but it shows jpegsâ by itself, and the ways existing shells do that (hacking escape code sequences) is very inefficient.
A proper shell, as Iâm suggesting, would be a GUI application, unless invoked from a vt100 terminal session.
Existing commands wouldnât change, by and large - rm, ls, cp et al remain as they were. Command invocation and argument passing wouldnât change, you still have argc and argv.
What we would add, is interactivity with a Scratch-alike visual command language interface, object introspection with the Haiku API, and a cohesive scripting language to wrap around both command invocation and function calls to the API.
So, circling back to the âScratch-likeâ command language interface. I am not going to front - what Iâm suggesting is straight up, Scratch for Adults, and without the weird âvideo game/turtle graphicsâ paradigm/model it works in.
Think of how tags work on some social media sites. You begin typing the tag, and a dropdown completion-box with matching tags shows up. You select or finish a tag, and that tag becomes a âchipâ, or a block, by itself.
Iâm thinking, a similar UX for that, for selecting and entering commands, and their arguments (options, files, objects).
The names of ls, cp, rm are fine, if you know what they mean; but they are cryptic to non-UNIX people.
So first, you start with a GUI, with a text entry box.
As you begin to enter a command, or keywords from a commandâs documentation, that command will light up in a drop-down box below the command line.
You can also select a command from the palette on the sidebar, or âlibraryâ, with the most commonly used and most recent commands up on top, and then other commands sorted by category among other things. (This palette is searchable, with a searchbar above it.) You drag over the command from the palette, and it âclicksâ into the command line, like a block; or you can type in the command, and itâll become a block.
So, if you type in delete, remove, or erase, a drop-down selection shows up, something like:
~ > erase
\rm- delete a file
\clear- clear the screen
\FilWip- clean-up temporary files
and selecting one of these, say rm would replace the âeraseâ in the command with it.
Now the library, on the sidebar, is that of the rm command. It now contains potential command options for the active command, files for the command to act on, or objects (like clipboard, windows) to be manipulated.
It shows a list like ârecursive, force, verboseâ - and allows you to click and drag those over, or to type in ârecursiveâ, hit TAB, and have it put -r on the command line.
Below that, is a file tree view, the âBrowserâ, starting from the current working directory, which is highlighted or tagged with a visual flag or bullet.
The browser presents you with options to select files to act on, either recursively or individually. Changing the working directory is easy with this view - right click the directory and âChange Directoryâ, for instance. You donât need to delete the command youâre working on to do so; itâll reflect in the shell that this is now the current directory.
For commands which work on other object types (e.g., URIs, the Haiku API, network addresses) the Browser view below the Library will change to match. If multiple object types are possible, it is tabbed.
Finally, for scripting, one can expand the entry line into a âworkpadâ, with the same affordances as the shell; but now you have additional commands for control flow, conditionals, parsing a return value from the called program, and the like. You can also make blocks out of other commands, and use those blocks themselves as commands, much like function definitions in Bash, except visually.
This shell internally represents all commands as an AST, and the commands are quickly parsed into tokens by which âgadgetsâ dispatch either syscalls like fork/execve, or program state control, and the like, internal to the shell.
A script can be saved in a couple ways and formats.
Normally, when you save the script, and it has a name, that name is now in your âlibraryâ as any other command. It saves to disk in your user directory under the shellâs folder or under ~/bin, along with your other personal library items and programs. Itâs in a binary AST representation in this place, and is âreconstitutedâ when edited.
Another option, is to save the script out to a file. You can save in the same compact AST representation, or as a plain-text document, not unlike a traditional shell scripting language. When that document is loaded into the shell, it is parsed and reconstituted into the visual paradigm of connected blocks of code and commands.
You can edit the plain text version independently of the shell, in âyour favorite text editorâ; and it can be easily diffed against on Git and other source-based VCS.
5 Likes
Well, the big companies all working on âscriptingâ the UI.
You can instrue your phone or tablet - there are assistants âŚ
and actually the brand new crazyness :
AI.
All script is a basically batch program - a program that executes programs with specific switches, attributes, call programs - in the background - write out statuses or not , execute shell command lines which sets up environmental changes, removes or delete stuffs.
Some of them contains interaction : ask some parameters, values, and based on those inputs executes the latter lines and of course those can controls also the built in
in case - do
or
if - then - else forks
if the script is really serious - e.g. an application installer script - admins do not use grahical interface basically ⌠however SAP and Oracle for example required a GUI so had to redirect the installer window from server to an X desktop using tunneling to be able to install but with securely.
Thus way GUI UI also can be scripted but it must be prepared.
This way the scripts are done by developers and the user only use the prepared version of âscriptâ in this case the developer must be smart and build up this script carefully as the user would only capable to give the values , parameters that changes in case tasks.
This is for what Null campaign here - a turnkey solution.
Like a phone OS service or app for Haiku - no surprise ⌠here are the app generation :-))
Remember if an Apple event you may seen - what kind of new features are spoken about - some service of an app became available in calendar or in chat program that enables this new convenient anything that will be so fancy or (more) usable and that app became more attractive or effective.
However me also recommended speech recognition and dictation capabilities to Haiku shell - but it is basically to reduce typing a mass volume of text. It would accelerate more stuff as input task. for example I could finish this post in a fraction of time related to the âlong timeâ until it was typed - even with overheard and this way need fixing of faulty words - or even with .the time of composing my saying.
EDIT1 : fixed typos.
EDIT#2 : added supplemental Apple event explanation.
EDIT#3 : Added quote of @PeterW to make it obvious to what question I had replied when I posted this.
I donât like making long effort posts just to have a troll scroll me way into backlogs.
Or, unless this isnât a troll: No, general-purpose chatGPT-style AI is not applicable.
At a base, ML may be useful for (in the context of the visual shell concept, above) suggestions or sorting the library by âvibesâ, or quickly scrubbing through documentation to produce those suggestions, but it is not useful for generating commands to interface with the system based on natural language processing.
As an IBM presentation once put it:
A COMPUTER CAN NEVER BE HELD ACCOUNTABLE
THEREFORE
A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION
4 Likes
Something like ffmpeg would definitely benefit from a âvisual shell composerâ approach over a âbespoke GUIâ.
And one could make meta-commands, blocks that specifically change how the shellâs Library behaves, for ffmpeg itself; and even program in previews, using Haikuâs Translators, to display PDFs, images or audio into the UI - and, through that interface, preview the video being edited, including selections for scrubbers (e.g., for start- and end-of-cut sections).