As I mentioned there, I wonder if terminals/shells are stuck in the past because the efforts are so diffuse. That is kind of natural in open source, but also a problem
On static typing, there is almost certainly something that can be improved about the shell, but this page doesn’t address a key problem – static typing doesn’t scale to the sofware on even a single machine (on Linux or Windows), let alone multiple machines:
Hey thanks for all the links! Some great stuff I hadn’t seen before
As I mentioned there, I wonder if terminals/shells are stuck in the past because the efforts are so diffuse. That is kind of natural in open source, but also a problem
On static typing, there is almost certainly something that can be improved about the shell, but this page doesn’t address a key problem – static typing doesn’t scale to the sofware on even a single machine (on Linux or Windows), let alone multiple machines:
scrapscript is specifically built so that all machines share the same types/data/code :)
This is one major reason I think scrapscript specifically has something new to offer to shell design! You don’t have to install libs/apps or copy/paste to access the scrapyard. You can imagine something like this:
silent (cat file.csv)
|> andyc/customers
-- ok [ andyc::customer { id = 123, name = "Joe" } ]
But I don’t know. This might just be an advanced case of NIH syndrome.
It would be cool if there was some survey of all those projects, to see what they did “wrong” and right. And what they have in common and where they differed
I think it’s a hard design / bootstrapping problem because it’s IPC, not something you can ever break (e.g. why the terminal itself is so crufty, why CSV is, etc.)
I should probably rename / refactor the wiki a bit to make it clear it’s an editable survey, and make it clear which ones are apps and which ones are protocols, etc.
This thread gave me the thought that there should be a CANONICAL site that hosts descriptions of all the main shells and is a jumping point to more info.
And then I thought “what a stupid idea - very few topics have canonical web sites” …
And THEN I thought “but wait actually most of the shells that are being actively developed at the moment are being developed by lobsters!” So you could actually do this.
(There’s someone from the fish team here too but I’ve forgotten their username.)
I’d like to see it taken further: make how I use my comp version controlled/saved. When I want to see how I did x some years ago, open up that notebook and look at the file diffs embedded, the commands executed with their output, etc. and let me page up and see what I’d tried previously.
I do this to some extent with org mode files today, but the downsides are significant enough that it’s just not easy to achieve.
Great idea! One of the nice things about the platform design is that it naturally supports elm-style time-travel debugging. It should be pretty cheap to store messages for later replay.
I’ve got a longer vision for how scrapscript is going to tackle diffs and version control, and smel will hopefully get all of that for free once implemented. Stay tuned!
You can record everything you do in any shell using asciinema. You can also configure your terminal such way that it always starts asciinema by default instead of bash. So everything will always be recorded automatically. (Unfortunately, as well as I understand, you will lose ability to change size of your terminals, because asciinema doesn’t support this.)
This page seems to be missing any reference at all to prior art, e.g. dozens of project like this:
https://domterm.org/index.html
https://github.com/unconed/TermKit - 14 years old, but looks better than the state of the art !!!
https://hyper.is/
https://github.com/ericfreese/rat
etc. etc.
https://github.com/oils-for-unix/oils/wiki/Interactive-Shell
Mentioned here:
https://lobste.rs/s/qwcov5/deja_vu_ghostly_cves_my_terminal_title#c_imqrsg
https://lobste.rs/s/xhcdg3/majjit_lsp#c_4agnik
As I mentioned there, I wonder if terminals/shells are stuck in the past because the efforts are so diffuse. That is kind of natural in open source, but also a problem
On static typing, there is almost certainly something that can be improved about the shell, but this page doesn’t address a key problem – static typing doesn’t scale to the sofware on even a single machine (on Linux or Windows), let alone multiple machines:
https://lobste.rs/s/sqtnxf/shells_are_two_things#c_pa4wqo
Hey thanks for all the links! Some great stuff I hadn’t seen before
scrapscript is specifically built so that all machines share the same types/data/code :)
This is one major reason I think scrapscript specifically has something new to offer to shell design! You don’t have to install libs/apps or copy/paste to access the scrapyard. You can imagine something like this:
But I don’t know. This might just be an advanced case of NIH syndrome.
Really appreciate the feedback!
For a while I was collecting “related work for new terminals/shells” here, so here are a bunch more links:
https://github.com/evmar/smash/blob/master/docs/related.md
Yup, that link is near the top of my wiki :-) https://github.com/oils-for-unix/oils/wiki/Interactive-Shell
It would be cool if there was some survey of all those projects, to see what they did “wrong” and right. And what they have in common and where they differed
I linked this survey from 2014, but I haven’t seen many others - http://waywardmonkeys.org/2014/10/10/rich-command-shells
I think it’s a hard design / bootstrapping problem because it’s IPC, not something you can ever break (e.g. why the terminal itself is so crufty, why CSV is, etc.)
I also remember this page about hyperlinks in terminals, which seemed to inspire a lot of argument at the bottom - https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda (adding this to the wiki)
I should probably rename / refactor the wiki a bit to make it clear it’s an editable survey, and make it clear which ones are apps and which ones are protocols, etc.
@evmar @andyc @ilyash @xiaq
This thread gave me the thought that there should be a CANONICAL site that hosts descriptions of all the main shells and is a jumping point to more info.
And then I thought “what a stupid idea - very few topics have canonical web sites” …
And THEN I thought “but wait actually most of the shells that are being actively developed at the moment are being developed by lobsters!” So you could actually do this.
(There’s someone from the fish team here too but I’ve forgotten their username.)
There are a bunch of detailed and comprehensive surveys here, and apparently people other than me actively edit them :-)
https://github.com/oils-for-unix/oils/wiki/Alternative-Shells
https://github.com/oils-for-unix/oils/wiki/Internal-DSLs-for-Shell
https://github.com/oils-for-unix/oils/wiki/Alternative-Regex-Syntax
https://github.com/oils-for-unix/oils/wiki/Survey-of-Config-Languages
The “Interactive Shell” one should be renamed / improved, as I mentioned … help is welcome
I somehow assumed that the first link here is the “canonical” de facto place. Thanks to Andy who already did the job!
And TIL that Steve Bourne is still with us, as in still living - I don’t know whether he’s on lobste.rs.
Also check out
vipe(1)from moreutils, it allows running the editor in the middle of pipelines.This is neat. Similar to some of my thoughts.
I’d like to see it taken further: make how I use my comp version controlled/saved. When I want to see how I did x some years ago, open up that notebook and look at the file diffs embedded, the commands executed with their output, etc. and let me page up and see what I’d tried previously.
I do this to some extent with org mode files today, but the downsides are significant enough that it’s just not easy to achieve.
Great idea! One of the nice things about the platform design is that it naturally supports elm-style time-travel debugging. It should be pretty cheap to store messages for later replay.
I’ve got a longer vision for how scrapscript is going to tackle diffs and version control, and smel will hopefully get all of that for free once implemented. Stay tuned!
Sounds cool! Wish you the best.
You can record everything you do in any shell using asciinema. You can also configure your terminal such way that it always starts asciinema by default instead of bash. So everything will always be recorded automatically. (Unfortunately, as well as I understand, you will lose ability to change size of your terminals, because asciinema doesn’t support this.)
Interesting idea. I’ll play with this sometime soon I think
Another piece I’d love to throw into the big list of inspirational links that I don’t see represented is the design document for @matklad ‘s abont:
https://github.com/matklad/abont
Specifically - for inspiration on how this interactivity might feel
Very neat! I recently realized that shells strength is pipelines/streaming of external tools, but it’s weak at adding a function in the middle of such a stream: https://blog.yosemitesam.ch/shell-a-stream-processing-language/ (refresh on error 500)
I think your post kinda boils down to a similar observation; Shell pipelining is also weak at user interactivity.