sirocyl

give me an MFD with tappable aliases at the very least.

give me a list of envvars I can paste the contents of by tapping their buttons. there's so much here that can be done with existing tools even

(this is a bit stream-of-consciousness writing here, and a lot of it is copied from things I noted earlier.)

honestly, I've done some brainstorming on what a shell should become, and I think I have some answers.

Ideally, you can operate this entire shell from a mouse or touchscreen, or a menu interface, without having to bring up a keyboard or open a manfile into another window, because all of the manipulable objects, shell commands, and all their possible arguments, are available from the library and browser panels, and their documentation is viewable inline.

This is a new shell, and it should act like it.

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.

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. Therefore, this will be a GUI application, unless it is launched from within a vt100-like/ANSI terminal session.

Make it a visual, and block-oriented agglutinative language.

I’m not talking about a node-based scripting environment (like Quartz Composer, Blender’s node graph UI, or Unreal’s Blueprint system) - I’m focusing more on a “lego”, agglutinative series of code and function blocks, which can themselves contain code and function blocks.

I’ve always had this idea of doing a shell as “Scratch, for adults.”
The gist of it is, you can freely enter commands line-by-line typed out, and they’ll be parsed into blocks transparently as you go along; or, you can attach together blocks to specify the operation that you’re performing, with transparent on-the-fly documentation and a menu or “library” of available commands to pull from.

This format would save to plain text, and be parsed into command blocks; or be saved as a compact token/AST form, and “reconstituted” on the fly.

Either way, it’s intended to be accessible to newcomers or less-experienced computer users, while not getting in the way of people who intend to program scripts for the shell like the way they’re used to. A skilled command wizard could hide away the panels and simplify the “coding block” UX to being little more than on-the-fly syntax highlighting; the code is entered by keyboard, as usual.

Reach into the desktop, and allow rich scripting through both API and UI.

This shell should also be able to comprehend and automate UI interactions, namespacing and identifying specific UI elements in terms of code, in a way that’s less liable to breakage. I’m thinking along the terms of AppleScript and Automator, on that end.

One UI puzzle that could be solved for automation tasks, is a drag-and-drop “connector” line, which you pull from the shell window to a specific UI element, and then that element is referenced into the code transparently.

It should also be able to do object introspection on the desktop model and API, where present, to provide a cohesive scripting language to wrap around both command invocation and function calls to the API.

this share has been in my drafts for almost the entire time I've been on this site (look at dat post number in the 4 millions!), because I've been meaning to write some thoughtful thoughts on this topic, but that's not going to happen before the eggbugalypse. So here's the semi-finished version, focusing on one particular related subtopic.

I want to add a couple of points that go in a somewhat different direction than the above posts. (Which I very much agree with - I think all of the ideas that @sirocyl listed are things I would like to see in a new shell-like environment.) My points are about how a new shell should ideally handle existing command line tools, which expect a traditional text terminal as the only UI and are unaware of any new concepts this shell introduces.

Process management (job control) is supposedly an important job of Unix-y shells, but (hot take incoming!) they are not actually very good at it, at least not by modern standards. If you've ever run more than one process at once in the same shell (intentionally or by accident), you know what I'm talking about. A new shell should do better here. My wishlist here is:

• The shell should support better interactive job control. There should be some UI for this that's more usable than the fg, bg, jobs, kill, etc. commands. (The macOS Terminal application actually does this to some extent! In the info window, it shows a list/tree with info about all processes running in the current terminal tab, and lets you interactively send signals via the context menu. This is an external feature and not integrated with the shell though, meaning that you can't use it to bring a different job to the foreground, for example.)
• The user should be able to readily interact with every running command, including the shell itself. The user shouldn't have to pause or interrupt any command to be able to switch to another command or the shell.
• The shell should isolate the terminal interaction of different commands. A command shouldn't be able to leave the terminal in a persistently broken state that messes up the shell or later commands. A later command shouldn't be able to overwrite or clear earlier output that came from something else. If the user runs multiple commands concurrently, their terminal IO shouldn't interfere with each other (unless the user explicitly requests otherwise).
• The output of all processes should be accessible from the shell for later reuse. The user shouldn't have to rerun a previous command just to be able to pipe or save its output. Ideally, it should even be possible to attach a pipe to a process that's still running.

And since we're on the topic of managing terminal IO better, a couple of other things that should be improved there (although these aren't directly related to job control):

• Line-oriented text input should be isolated from the terminal used for output. The unfinished input typed by the user shouldn't get messed up just because a program produced output. Typing a long line or using tab completion shouldn't permanently shift the terminal output up a few lines. Scrolling up in the output history should leave the input line visible at the bottom, so that the user can type while looking at older output.
• If a program displays something at an absolute position in the terminal, that should be isolated from line-based output. It should be possible to display something like a progress bar or a status line together with simple text output without the two fighting with each other. A full-screen TUI should be able to print to stderr without messing up the layout.

And this brings me back to the original topic. A good way to address these issues would be to give the shell its own proper GUI, or at least integrate it with a GUI that's much richer than a regular terminal emulator. The output history should consist of separate sections for every executed command, and the user should be able to interact with those - e. g. collapsing a long output section or selecting it to be piped into a new process. The input line, prompt, and terminal output should be actual separate GUI elements, so that it's impossible for them to interfere with each other.

But at the same time, I get the impression that most of these issues (especially the ones from the first list) could be addressed by a traditional terminal-based shell as well. Each process started by the shell would receive a fresh virtual terminal rather than directly reusing the shell's terminal, and then it would be the shell's job to forward all processes' terminals in an orderly fashion to the shell's terminal, which the user interacts with. I suppose this "forwarding in an orderly fashion" is the hard part - to make that work, the shell would have to do something very similar to tmux and screen, i. e. implementing its own terminal emulator.

Really, like, half of what I'm asking for would be covered by integrating a shell with tmux or screen so that every command receives its own window/pane/terminal in tmux/screen. It wouldn't be exactly what I'm thinking of, but it would be a good starting point. Surely someone must have attempted something like this before?