Schemesh is intended as an interactive shell and REPL:
it supports line editing, autocompletion, searchable history, aliases, builtins,
a customizable prompt, and automatic loading of `~/.config/schemesh/repl_init.ss`.
Most importantly, it has job control (CTRL+Z, `fg`, `bg` etc.) and recognizes and extends
Unix shell syntax for starting, redirecting and composing jobs.
An example:
find (lisp-expression-returning-some-string) -type f | xargs ls 2>/dev/null >> ls.log &
> Scsh, in the current release, is primarily designed for the writing of shell scripts -- programming. It is not a very comfortable system for interactive command use: the current release lacks job control, command-line editing, a terse, convenient command syntax, and it does not read in an initialisation file analogous to .login or .profile
I really like how you don’t sacrifice complete command-line first shell feel, and escaping into a sane language with real datastructures is literally one character away.
Rather than the tclsh way of saying “we’ll just make the Lisp seem really shelly” which is a dud to anyone who is not a lisper.
Now, it’d be really cool if schemesh had a TUI library at the maturity level of Ratatui.
So... it sacrifices sub-shell syntax with parentheses being hijacked for Scheme. Have you also lost $(...) shell interpolation as the saner alternative to `...`?
It does not sacrifice sub-shell syntax: it is fully supported,
I just had to rename it from ( ... ) to [ ... ] to avoid conflicts with ( ... ) that switches to lisp syntax
Also, both $(...) and `...` shell interpolation are fully supported.
The only thing I intentionally sacrificed is shell flow control: schemesh shell syntax does not have the builtins 'case' 'for' 'if' 'while' etc.
In practically all examples I tried, escaping to Scheme for loops and conditional code works better: it avoids the usual pitfalls related to shell string splitting, and usually results in more readable code too, at least for a Lisper
Note: there's also some additional parsing logic to distinguish between sub-shell syntax [ ... ] and wildcard patterns that use [ ... ] as well
SCSH is a shell embedded in Scheme, i.e. it's a Scheme library that lets you easily create unix processes in Scheme. Schemesh is Scheme embedded in a shell, i.e. it's a shell that lets you easily call Scheme code.
For example, if you type:
ls
in schemesh you will execute the "ls" command and get a directory listing, whereas in scsh you will get the value of a variable named "ls".
[UPDATE] Also, as cosmos0072 notes in a sibling comment, schemesh has shell-like features like line editing, autocompletion, searchable history, aliases, builtins, etc.
This is a common question :)
Schemesh is intended as an interactive shell and REPL: it supports line editing, autocompletion, searchable history, aliases, builtins, a customizable prompt, and automatic loading of `~/.config/schemesh/repl_init.ss`.
Most importantly, it has job control (CTRL+Z, `fg`, `bg` etc.) and recognizes and extends Unix shell syntax for starting, redirecting and composing jobs. An example:
find (lisp-expression-returning-some-string) -type f | xargs ls 2>/dev/null >> ls.log &
Scsh has none of the above features. As stated in https://scsh.net/docu/html/man-Z-H-2.html#node_sec_1.4
> Scsh, in the current release, is primarily designed for the writing of shell scripts -- programming. It is not a very comfortable system for interactive command use: the current release lacks job control, command-line editing, a terse, convenient command syntax, and it does not read in an initialisation file analogous to .login or .profile
I really like how you don’t sacrifice complete command-line first shell feel, and escaping into a sane language with real datastructures is literally one character away.
Rather than the tclsh way of saying “we’ll just make the Lisp seem really shelly” which is a dud to anyone who is not a lisper.
Now, it’d be really cool if schemesh had a TUI library at the maturity level of Ratatui.
So... it sacrifices sub-shell syntax with parentheses being hijacked for Scheme. Have you also lost $(...) shell interpolation as the saner alternative to `...`?
It does not sacrifice sub-shell syntax: it is fully supported, I just had to rename it from ( ... ) to [ ... ] to avoid conflicts with ( ... ) that switches to lisp syntax
Also, both $(...) and `...` shell interpolation are fully supported.
The only thing I intentionally sacrificed is shell flow control: schemesh shell syntax does not have the builtins 'case' 'for' 'if' 'while' etc.
In practically all examples I tried, escaping to Scheme for loops and conditional code works better: it avoids the usual pitfalls related to shell string splitting, and usually results in more readable code too, at least for a Lisper
Note: there's also some additional parsing logic to distinguish between sub-shell syntax [ ... ] and wildcard patterns that use [ ... ] as well
2 replies →
> This is a common question :)
It'd be really great if you could put your answer in the readme. It was the first question that came to my mind when looking at your project.
I'm looking forward to trying out schemesh!
SCSH is a shell embedded in Scheme, i.e. it's a Scheme library that lets you easily create unix processes in Scheme. Schemesh is Scheme embedded in a shell, i.e. it's a shell that lets you easily call Scheme code.
For example, if you type:
in schemesh you will execute the "ls" command and get a directory listing, whereas in scsh you will get the value of a variable named "ls".
[UPDATE] Also, as cosmos0072 notes in a sibling comment, schemesh has shell-like features like line editing, autocompletion, searchable history, aliases, builtins, etc.