3 ms·

Looks like a lot of great work went into this. But I'm not sure I want to see CLI applications continue going down this path. Maybe I'm missing the point of thi

by chrsw 5y ago

Looks like a lot of great work went into this. But I'm not sure I want to see CLI applications continue going down this path. Maybe I'm missing the point of this, but I like my terminal applications simple, small and easy to drop into the rest of the shell ecosystem. This means applictions willing to accept input from either the keyboard interactively or from a stdin input stream of bytes and lines. Output should be a simple, structured, human readable and machine consumable format for easy drop into pipelines and shells scripts.

azinman2 5y ago
For me the biggest issue is not having history. That’s the value of the terminal - I can scroll up and see previous interactions, copy paste from them, etc. That said I don’t think the point of this is to replace sed, or other unix-y tools where you’re having pipeline-oriented programs. It’s full blown apps inside of the terminal that might otherwise be in the browser or in a GUI. Something where you’re seeing things update or otherwise interacting such that you could never grab it’s out for a shell script nor would want to.. like running a REPL or top.
- zmmmmm 5y ago
  I agree but to the parent's point, there is still something non-native about these terminal apps that essentially draw a full blown GUI and build a custom application in there. What I want is terminal apps that seamlessly integrate with all the standard conventions of the terminal. Your example of history is a great one. Another is, wherever possible enabling things like vi-style navigation, minimal need to move your hands off the home row, seamless integration with command line tools (implementing a search function - don't! let me pipe it through my own one, eg: grep). As soon as I have to hit function keys, manually navigate to control UI elements etc. it's just a really bad recreation of what we already have in the browser.
  - usrn 5y ago
    What you're looking for is "GNU Readline."
  - danmur 5y ago
    I think there's a space for this. ncdu for example is invaluable to me.

by chrsw 5y ago

azinman2 5y ago

For me the biggest issue is not having history. That’s the value of the terminal - I can scroll up and see previous interactions, copy paste from them, etc. That said I don’t think the point of this is to replace sed, or other unix-y tools where you’re having pipeline-oriented programs. It’s full blown apps inside of the terminal that might otherwise be in the browser or in a GUI. Something where you’re seeing things update or otherwise interacting such that you could never grab it’s out for a shell script nor would want to.. like running a REPL or top.

zmmmmm 5y ago
I agree but to the parent's point, there is still something non-native about these terminal apps that essentially draw a full blown GUI and build a custom application in there. What I want is terminal apps that seamlessly integrate with all the standard conventions of the terminal. Your example of history is a great one. Another is, wherever possible enabling things like vi-style navigation, minimal need to move your hands off the home row, seamless integration with command line tools (implementing a search function - don't! let me pipe it through my own one, eg: grep). As soon as I have to hit function keys, manually navigate to control UI elements etc. it's just a really bad recreation of what we already have in the browser.
- usrn 5y ago
  What you're looking for is "GNU Readline."
- danmur 5y ago
  I think there's a space for this. ncdu for example is invaluable to me.