| So, this project starts about shell, then I see it also aims to implement full-blown terminal emulator and a lot of new very ambitious features, and then it invites terminal-based apps to use new capabilities of it, so it would be best usable only if the whole ecosystem of compatible apps appear. Unfortulately, I'm pessimistic. Also, would like to comment on project's README. Not meaning to be harsh. > The shells never caught up. Wrong. To prove this, it is enought to see that almost none of "features" is new in comparsion with traditional terminals. > Not to block, allow typing next commands even if previous command(s) still run(s). Got a plenty of ways to handle that with shell. Backgrounding, GNU Screen, Tmux. > Open issue: how to deal with a command that requires interaction. Oh yeah, you've invented a thing and don't know how to use it with real-world apps. Happens. > Provide good feedback. In GUI for example, this can be green / red icon Enhanced setting of shell's "PS1" variable gives you good indication of exit code of last app (color + text + whatever, you may even use audio if you want). I'm using it for years. > All operations made via a UI, including mouse operations in GUI must have and display textual representation, allowing to copy / paste / save to a file / send to friend. Sure, why not, but all this is possible with shells. Both native consoles (with gpm) and X11 terminal apps, and also Tmux has its own possibilities to handle clipboard. > Different UI modules must exist Lots of people was playing around with shells via IRC or XMPP ages ago. > Web Good luck handling keystrokes with tricky keycodes, and preserving all other standard terminal features. BTW I thought this project aims another shell, but this sounds like requiring another terminal emulator. I'd be glad to hear we have powerful web-based terminal emulator, but this feels very laborous. > allow multiple users to collaborate Screen/Tmux. > some rw, some ro Seems lacking in tmux at the moment, but possible to implement on its own, without reinventing everything else. > Most of the data dealt with is tables. List of files, list of instances in a cloud, list of load balancers. Amazing that none of current shell tools (I heard of) don't treat the data as such It is discouraged to parse textual output of shell programs unless app clearly guarantees unchanging parsable/consumable format (with specific options you use). Quite often there's another, more reliable way to mine information than parsing of output of general-purpose program. > Allow editing it and saving to file some_program | vim - Then, in editor, edit and save. Done.
If you add too many specific usecases into the core, you end up with bloated interface. |
This is actually my only objection and the only feedback I'd make to the author. Contra some of the other posters here, I fully agree shell is a mess and that the basic root cause of the mess is that you can not straddle interactive use and programmatic use with one language. But something a bit smaller needs to be bit off.
I'd also suggest that most shells have already got the interactive use case sufficiently covered and that the low-hanging fruit is in the command case. Perl is perhaps the best language that functions as a programming-shell replacement, but using it for a while reveals it still has many significant issues in that use case. Even with modules, it pipes surprisingly poorly. It tends to make stream processing harder than it needs to be, unless "one line at a time" works for you. It's got a lot of nasty syntax that is arguably optimized for big program use cases that doesn't make sense when replacing shell scripts. When being used for shell programming, it basically shares C's abject failures when it comes to error handling, making it range between bizarrely difficult (I have to left-shift the result of system to get the actual exit code?) to almost-impossible-to-remember (backticks) to get errors properly handled. It has no concurrency story or any particular "run on multiple targets" ability (though I confess I don't know what that looks like necessarily; in my head it rather becomes puppet or ansible fairly quickly).
There's room here, but it's going to be an uphill battle.