3 ms·

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 c

by 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.

by 0xCMP 5y ago

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.