Wow, CLIM looks cool! Feels feels like a kind of shell that is really useful and usable. Unfortunately Wikipedia says it's just a programming interface for creating GUIs (which I'm going to give a try nevertheless, I actually happen to be interested in creating GUIs). I wish my actual terminal shell was like that and LISP was the language I interacted with it in. Writing complex commands, needless to say scripts in bash is such a headache...
> Writing complex commands, needless to say scripts in bash is such a headache...
For shell scripting, I cannot recommend the linter, shellcheck, enough. With editor integration it's abolutely glorious. Shellcheck will point out all kinds of gotchas and even tags each warning with a uid, so you chech out the rationale and extra info on the wiki.
I actually started working on a guile shell that parses a bash-like command line to a guile form. Any parenthesised form is executed as guile directly with some nice macros/functions to make processes easier
Cool! I can't wait to try it. But make sure it implements rainbow parentheses and powerful intuitive autocompletion. These former is essential to make a LISP editor usable, the latter is essential to make it cool enough for people to care trying it.
I haven't gotten to implementing the TUI yet :) in the beginning it will probably just be a readline-based prompt, but when I have implemented ANSI escape sequence parsing in ncurses I will get to writing a proper ncurses TUI.
TUI (or even GUI) is a great thing I would be amazed to see a good shell equipped with yet it is not really necessary as far as I understand. Take a look at the FISH shell - it is quite colourful and has reasonable (not perfect but the best I've seen so far and already helpful) autocompletion already.
That seems very much like what I am trying to achieve, but with guile instead. That's a cool way to use #lang. I have been writing a PEG parser to parse the command line using guile-PEG. I'll install your shell and play with it some.
Edit: My idea is to use the traditional Unix pipeline with forks and file descriptors. Does rash foreground processes like vim?
Rash only forks to launch processes, and it's all behind Racket's `subprocess` function. So there is no notion of eg. a forked subshell. But the `subprocess` function lets you get the subprocess file descriptors (as a special kind of port) or redirect subprocess IO to the ports of your choice. While pipeline segments that use Racket functions can pass each other arbitrary objects rather than just doing byte-level IO, pipeline segments that are just subprocesses do traditional Unix-style pipeline IO. And you can redirect a pipeline's input/output/error streams to arbitrary ports.
You can run pipelines in the background with Rash, but I haven't implemented job control yet, so I don't have proper handling for eg. auto-suspending a background TUI process and terminal control. (This ends up not being that big of a deal for most use, I find, though I intend to write better job control eventually.) I don't remember what Vim does off the top of my head, but I think running processes blocks Vim. Background pipelines don't block Rash, but if you don't specify to run one in the background the default behavior is to cause the current thread to wait for it to finish.
I look forward to a day when the rich command shells are treated no differently than the other 99% of command shells. Shell inequality is not discussed enough and often pushed under the rug. Only with open dialog and full transparency can we combat this injustice.
10 comments
[ 4.4 ms ] story [ 40.9 ms ] threadFor shell scripting, I cannot recommend the linter, shellcheck, enough. With editor integration it's abolutely glorious. Shellcheck will point out all kinds of gotchas and even tags each warning with a uid, so you chech out the rationale and extra info on the wiki.
https://www.shellcheck.net/
[1] http://rash-lang.org
Edit: My idea is to use the traditional Unix pipeline with forks and file descriptors. Does rash foreground processes like vim?
You can run pipelines in the background with Rash, but I haven't implemented job control yet, so I don't have proper handling for eg. auto-suspending a background TUI process and terminal control. (This ends up not being that big of a deal for most use, I find, though I intend to write better job control eventually.) I don't remember what Vim does off the top of my head, but I think running processes blocks Vim. Background pipelines don't block Rash, but if you don't specify to run one in the background the default behavior is to cause the current thread to wait for it to finish.