The Wizard and His Shell: What Happens When You Kill the Shell?

It is great to see people experimenting with this but I do not really see from the videos anything we can't do today. So no need to kill the shell or anybody.

Innovation in terminals and shells is hard and slow since what we have today is already very very good and flexible.

What we might need is:

- A common standard for graphics,

- A good, sane web browser (very hard),

- A sane way to automatically change text size depending on the context,

- Probably some specialized, local LLM to ease interactions,

- Some form of sane STT and TTS so we can interact with terminal hand free while driving for example.

This feels… silly to me. Sorry, I think the idea of the project is in the right place, and the features look compelling enough that I would like to download the beta. But if you think about it for even a second, the logical conclusion of the arguments presented would be the removal of the terminal almost entirely, and at that point is it even a terminal?

Take git for example. When I was learning git I did it entirely through the command line. The first time I used a real GUI git client was the last day I ever willingly did day to day git operations in a terminal. (Outside of scripting CI/CD pipelines or something.) Isn’t this just an admission that no matter how good your terminal is, git is better accessed through a GUI?

Or look at the environ command, where the demo proudly shows editing environment variables as a table, something that Windows has supported in a real GUI since, like, Windows 7?

I think the author has a long way to go before they declare terminals dead. Here’s some ideas I would be really excited to see:

* A terminal-aware split pane file manager. One pane is a directory tree, the other is a terminal. Clicking up and down the folder automatically changes the working directory of the terminal. Double clicking an executable or script runs it in that terminal, showing the output. Actions such as moving, copying, etc are saved to history and copy-pasteable. Terminal output can be saved to a file with a toolbar button or right-click menu. Code running in the terminal can be edited using normal CUA shortcuts and you can click to select or position the cursor.

* A terminal history browser that lets you interact with previous commands and re-run them, perhaps like a Jupyter notebook. You can permanently save and re-use snippets in normal .sh format to use scripts.

* A true bash/zsh debugger that lets you step one by one through commands, set breakpoints and watches, see the state of the environment and variables, etc., all in a GUI that emulates debuggers from other paradigms.

* A git GUI that lets you record “macros” that are just bash scripts. Imagine cloning a repo, checking out a tag, creating a new branch, and applying a patch or something. Then, you could click “Save” and have that be a repeatable script that runs anywhere.

I'm no expert regarding the shell. I guess I've only spent 0.01% of my life in it. But I want to say "Hear the guy out". IMHO, there's _got_ to be room for incorporating new stuff, however good the old stuff is. The horse and cart were great, but the car, the automobile wow!

Fantastic write up. I can't imagine the challenges they're working against here.

It's great to see innovation in the Terminal space. It's an interesting problem to tackle, because _so much_ of our interaction with computers (and therefore people and other computers) is done through the medium of text, and so much of our recorded knowledge is in books and other texts. It's hard to take a text-based interface out of the equation.

I, for one, would love to see a more generic, non-TTY text-based interface for systems management. You kind of get it with PowerShell, but then you're also sacrificing text-mangling for objects, which aren't as flexible (to me). And marrying yourself to a system that feels verbose and half-baked on non-Microsoft platforms.

So, for the time being, you can pry the terminal from my cold dead cursor.