5 ms·
Educate me then. Is Hyper unable to encroach onto the product feature space of the shell due to a particularly rigid terminology? Are the reasons for the curr
by lhnz 10y ago
Educate me then.
Is Hyper unable to encroach onto the product feature space of the shell due to a particularly rigid terminology?
Are the reasons for the current separation of concerns still optimal?
- yladiz 10y agoI would say the separation of concerns is very optimal right now. The terminal emulates the shell, and that's it; there's nothing going on in between or in the terminal besides displaying what the shell outputs. I don't really need mixing of the two, which this looks like it does. For example, if I entered a URL into the terminal, it should be up to the shell to interpret it, not the terminal. This is not to say that I don't mind "magic" -- I removed the `git` prefix from my git commands because I like typing `add .` rather than `git add .` all the time -- but I don't want my terminal to do it, I want my shell to.
- lhnz 10y agoIs customising the shell prompt with a PS1 variable good though? The result often lacks clarity. I don't think the shell should be handling styling. I also think the shell became less useful when modern application development began to happen on the Web. More should be done to make it easier to interact with Web applications from the command line.
- deadbunny 10y agoSorry but webapps make up a tiny portion of what I need to interact with on the CLI as an admin. When I do need to interact with webapps I use an API using curl or python (depending what I need to do). When do you need to interact heavily with a webapp? Maybe I'm missing something here.
- lhnz 10y agoFor example, say I ran a command to show disk space usage. Perhaps I would like to pipe the output into a d3 visualisation and see it directly within the terminal without context switching. Why shouldn't I be allowed to do this? Have you read "The Visual Display of Quantitative Information" by Edward Tufte? Text isn't the best representation of all types of data. Imagine also that I wanted to represent a table of data within an Excel style spreadsheet. This could be useful as it could define affordances for a user such as the ability to select rows and columns, and to sort or filter in realtime.
- deadbunny 10y agoI can see the value in that, I don't see how looking across to a browser which has rendered the results of a command piped into a script is the end of the world. One issue I have with bluring the lines is you open yourself up to a huge attack vector. If I can craft the output of my shell command to get code execution within your terminal I can now do anything, anything on any system you have access to.
- lhnz 10y agoYes - it is a possible attack vector but that doesn't necessarily mean it shouldn't be attempted.
- gknoy 10y agoA shell is a program that interprets input and such -- the interactive Bash shell is the same program that interprets scripts written for it. You can remotely call shells and interact with them without showing anything to one's terminal. A terminal emulator connects your keyboard, mouse, and eyeballs to inputs/outputs of the shell. Those are terrible explanations, I'm sorry.
- daveloyall 10y agoKnowing what your shell will and will not do and what your terminal will and will not do is vital for writing good CLI applications.
- deadbunny 10y agoRather than just repeat the first Google result I'll link it[1] as it gives a far more thorough answer than I would. While I welcome innovation I would not want my terminal to be in charge of much more than rendering text and inserting keypresses. Yes there are some helpful things your terminal emulator can do like multiplexing, repeating input across instances, scrolling, text resizing/flowing but these are strictly UI features at no point is the terminal in charge of interacting with the underlying system, that's what the shell is for. The example of typing a URL and having it be rendered by the terminal blurs this line, it is intercepting a command you've typed into your shell (what is essentially a system command) and being executed in the terminal, not the shell. If they want to blur that boundary then they can crack on, it will lead to pain and anguish down the line for the users especially when they find themselves out of their comfort zone without their toys. 1. http://superuser.com/a/144668 http://superuser.com/a/144668
- perhonen 10y agoIt's pretty simple. bash, zsh, fish, powershell are shells. iTerm, Terminal, and Hyper are terminals - wrappers around a shell.