5 ms·

I've felt for a long time that we need a better Shell, but I think the next evolution is combining the Terminal and Shell together. I've never thought that wha

• SkyMarshal 5y ago
  Sounds like what notty was trying to do, though it seems unmaintained for 5yrs. https://github.com/withoutboats/notty/ https://github.com/withoutboats/notty/
• jolmg 5y ago
  > I've never thought that what was good about the command line was that a terminal and shell are different... I don't actually know anyone who uses plain TTYs for their Shell. If you use a shell today it's 99% running inside of [iTerm2,terminal.app,Gnome Shell,uxrvt,alacritty,etc] on top of a window system. Interactive shells can be used without opening a graphical terminal. Simple examples are calling :shell from vim, or S in the `ranger` file manager, or entering a docker container, or using ssh. Terminals can also be used without a shell. For example, I have keybindings for opening a terminal with a file manager, or with vim, or with vim with the clipboard contents and special vim keybindings to handle it, or with nothing on it (a process that sends a stop signal to itself). This last one is to get a new unused terminal window to which I can redirect stuff. For example, with `gdb -tty` I can interact with a program from one terminal, while having another terminal control it with gdb. They really are 2 separate types of programs that are useful on their own, and their separation allows for more flexible handling, like how separate programs can take control of the terminal at separate times, like how it happens with vim's :shell, etc.
  • 0xCMP 5y ago
    The "shell" I'm suggesting still would run all those programs they just would be a direct child process of what would normally be just a terminal instead of a child of a bash process. It would absolutely need to have some kind of fallback mode when escape codes are used. I am not sure how the gdb example works, but one thing I wanted was the ability to manage multiple programs running at the same time. Maybe it'd still be another shell instance running gdb attached to your original process. Maybe the shell could have a feature to execute a `gdb -tty` process with arguments pointing it at the pid. I think it's a solvable thing which would absolutely be different, but an improvement.
    • jolmg 5y ago
      > The "shell" I'm suggesting still would run all those programs they just would be a direct child process of what would normally be just a terminal instead of a child of a bash process. I think you misunderstood. As I understand it, if you run in the shell: $ yourshell it would open up a new terminal/shell combination, a new window. In there, if you run vim, and then you `:set shell=yourshell`, then `:shell`, would that open up a new window or work like the shells of today and give a prompt in the same window? If you run `:!make`, would that open up a new window, print the output there, then close a millisecond later without giving the user a chance to review? If you `usermod -s /bin/yourshell $your_user`, would logging into that computer via ssh cause it to try to open a new window locally and not provide a prompt to sshd like shells of today do? If you run vim from an ssh session, then you do `:!make`, would the user see the output anywhere? > I am not sure how the gdb example works It redirects the std file descriptors of the child process it's debugging to the terminal specified, like how one would do with `< $empty_tty &> $empty_tty`. This is so that gdb can be controlled from the terminal it was launched from without the child process interfering in terminal input/output, and at the same time allowing one to interact with that child process. E.g. `gdb -tty $empty_tty htop` would have you control `gdb` from the terminal invoked from, and `htop` from `$empty_tty`. > one thing I wanted was the ability to manage multiple programs running at the same time Shells have mechanisms for that. Terminals too. > Maybe the shell could have a feature to execute a `gdb -tty` process with arguments pointing it at the pid. `gdb -tty` is an example. The idea has uses beyond gdb. If you're debugging a program, you can edit the source at a specific point to run a REPL and have its input and output come from the terminal specified. It could be an already established unused terminal to keep history in the scrollback buffer, or a new terminal. Whatever the case, a forced shell gets in the way. More than anything, the core issue with the idea is that I see no benefit at all from combining the shell and terminal. That terminal/shell combination still needs to do what terminals of today do so that other programs can use it to interact with the user. I'm not even talking about escape sequences, just read and write. And if it's providing that, why would the shell need to be combined with it? If it can be separated, it's better separated. That's more in-line with the unix philosophy: 1. Write programs that do one thing and do it well. 2. Write programs to work together. It also allows users to switch shells or terminals as they'd prefer. They don't need to consider giving up terminal features because they don't like the shell or vice versa.
• oauea 5y ago
  Well, there is SSH. But better integration between shell and terminal could be hugely useful.
• nrdvana 5y ago
  The next evolution of the terminal (text array of characters with positioning drawing escape codes) was the graphics array of pixels with drawing API calls. The problem with graphics arrays is when you try to run them over a remote connection. For low bandwidth situations, you end up with hacks like downgrading to 8 bit color or disabling mouse-move events, both of which make some interfaces less usable. Then you also get the problem of scripting, where there isn’t a consistent way to deliver input to the applications. HTML and HTTP can be seen as yet another implementation of portable networkable user interfaces, and they are easier to script than graphical apps, but in the end, writing a web app or client is still a hundred times more effort than printing text on a terminal. Many people have thought of many ideas more advanced than terminals, but the terminals persist due to their superiority at just being simple, flexible, and fast. It is absolutely possible to “make a better terminal” though. But anyone who does has an uphill battle for adoption. (context: I was bound and determined to make a better terminal 20 years ago, but eventually gave up on the idea after getting familiar with existing tech and deciding it was good enough for me. Same with Bash, though I still think it’s a horrible language and should be replaced eventually)
  • 0xCMP 5y ago
    What I am mostly suggesting is iterative. We wouldn't switch to shipping graphics because as you say they're bandwidth intensive. RDP is not the right answer however useful it is for some things. But a shell+terminal hybrid focused on running processes, managing outputs, and making it easier for the user to run programs could do a lot of that remotely with a helper program similar to how tmux and git binaries need to be on the remote system. Or how vscode runs a fairly beefy system in order to support remote coding that not only allows editing code remotely with auto complete, but lets you launch multiple terminals to run commands. In a sense I'm really saying: we have like 80-90% of what a "modern" shell could look like in vs code remote... why can't we just make the shell like that? One thing which I do not have a good solution for is input because I don't know exactly how reliably a shell would know it's being asked for input from the application. The other thing being that I think this shell could support a legacy mode which is triggered by those escape codes, but most apps don't do that. As you said they just print text cause it's easy and fast. That's exactly what my python scripts at work do and a better shell that I suggest could handle plain text pretty easily. The issue is things like Vim, Emacs, Tmux, and other curses-like apps. But that could be a fallback rather than the happy path.