3 ms·

This looks pretty cool! I agree -- a big reason I like Unix, and find it productive, is that it's "shallow and composable". But GUIs have long been a weakness

by chubot 2y ago

This looks pretty cool! I agree -- a big reason I like Unix, and find it productive, is that it's "shallow and composable". But GUIs have long been a weakness. I guess because there are many "global" concerns -- whether a UI is nice isn't a "modular" property. Personally I would more of a UI, but still retain automation That is, the property of shell where I can just saved what I typed in a file, and then run it later And modify it and run it again Or I can copy and paste a command, send it to my friend in an e-mail, etc. --- As context, I've been working on a from-scratch shell for many years, and it has a "headless mode" meant for GUIs. There are real demos that other people have written, but nobody's working on it at the moment. Screenshots: https://www.oilshell.org/blog/2023/12/screencasts.html#headless-protocol-oils-web_shell https://www.oilshell.org/blog/2023/12/screencasts.html#headl... https://www.oilshell.org/blog/tags.html?tag=headless#headless https://www.oilshell.org/blog/tags.html?tag=headless#headles... More links here - https://github.com/oilshell/oil/wiki/Interactive-Shell https://github.com/oilshell/oil/wiki/Interactive-Shell - some interesting (inactive) projects like Xiki If you find the need for a compatible shell that's divorced from the terminal, or a NEW shell that is, feel free to let me know (by e-mail or https://oilshell.zulipchat.com https://oilshell.zulipchat.com ) Basically we need to people to test out the headless protocol and tell us how it can be improved. I think we should make a shell GUI that HAS a terminal, but IS NOT a terminal -- which looks like it has some relation to what you're building Right now we're working mostly on the new YSH language, but I'd like to revive the GUI work too ... I'm not an experienced UI programmer, so it would be nice to have some different viewpoints :) --- Also, I'm a big fan of ggplot, so I'm glad you included it there. Actually ggplot is exactly where I miss having graphics in shell!

williamcotton 2y ago
I’m going to play around a little bit with this headless mode and see if I can come up with anything interesting! Is there a place y’all hang out or a way you communicate? I foresee needing some guidance in places.
- chubot 2y ago
  Oh yes feel free to join https://oilshell.zulipchat.com/ https://oilshell.zulipchat.com/ -- there is a whole #shell-gui channel . We are mainly developing OSH and YSH now, but it would be nice to work on the interactive shell too The key idea is that OSH and YSH can run "headless" with the "FANOS" protocol (file descriptors and netstrings over unix domain socket), which has a tiny implementations in C and Python The reason we use FD passing with Unix sockets is so that anything that uses terminal still works: ls --color pip install cargo build All these programs will output ANSI color if `isatty(stdout)` is true (roughly speaking). Most people didn't quite get that -- they thought we should use "nREPL" or something -- but my opinion is that you really need a specific protocol to communicate with a shell, because a shell spawns other programs you still want to work. --- Here is a pure Python 3 implementation of the recv() side of FANOS in only ~100 lines https://github.com/oilshell/oil/blob/master/client/py_fanos.py https://github.com/oilshell/oil/blob/master/client/py_fanos.... It uses the recvmsg() binding . I'm pretty sure node.js has that too? i.e. it has Unix domain socket support --- Anyway, thanks for taking a look - we're interested in feedback!
- chubot 2y ago
  Oh also, my feeling of why this may be interesting is if you think "I want to write a GUI for shell, but I can't modify the bash source code to do what I want" That is, the shell itself is a limitation OSH is the most bash-compatible shell by a mile, AND we can easily add new hooks and so forth. I think most stuff can be already done with FANOS, but I think completion is one area that needs some testing / feedback. For example, I imagine that when constructing a pipeline, you might want to complete exactly what's available -- like shell functions that the user has defined ?

by chubot 2y ago

williamcotton 2y ago

I’m going to play around a little bit with this headless mode and see if I can come up with anything interesting! Is there a place y’all hang out or a way you communicate? I foresee needing some guidance in places.

chubot 2y ago
Oh yes feel free to join https://oilshell.zulipchat.com/ https://oilshell.zulipchat.com/ -- there is a whole #shell-gui channel . We are mainly developing OSH and YSH now, but it would be nice to work on the interactive shell too The key idea is that OSH and YSH can run "headless" with the "FANOS" protocol (file descriptors and netstrings over unix domain socket), which has a tiny implementations in C and Python The reason we use FD passing with Unix sockets is so that anything that uses terminal still works: ls --color pip install cargo build All these programs will output ANSI color if `isatty(stdout)` is true (roughly speaking). Most people didn't quite get that -- they thought we should use "nREPL" or something -- but my opinion is that you really need a specific protocol to communicate with a shell, because a shell spawns other programs you still want to work. --- Here is a pure Python 3 implementation of the recv() side of FANOS in only ~100 lines https://github.com/oilshell/oil/blob/master/client/py_fanos.py https://github.com/oilshell/oil/blob/master/client/py_fanos.... It uses the recvmsg() binding . I'm pretty sure node.js has that too? i.e. it has Unix domain socket support --- Anyway, thanks for taking a look - we're interested in feedback!
chubot 2y ago
Oh also, my feeling of why this may be interesting is if you think "I want to write a GUI for shell, but I can't modify the bash source code to do what I want" That is, the shell itself is a limitation OSH is the most bash-compatible shell by a mile, AND we can easily add new hooks and so forth. I think most stuff can be already done with FANOS, but I think completion is one area that needs some testing / feedback. For example, I imagine that when constructing a pipeline, you might want to complete exactly what's available -- like shell functions that the user has defined ?