4 ms·

This is a common question :) Schemesh is intended as an interactive shell and REPL: it supports line editing, autocompletion, searchable history, aliases, buil

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 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

sshine 2y ago
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 `...`?
- cosmos0072 2y ago
  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
  - sshine 2y ago
    Then [ shadows the sh executable aliased from ‘test’ so that you can no longer do [ some conditional ] && ... But have to write test some conditional && ...
    - cosmos0072 2y ago
      That's true. In shells, "test" and "[" are often used after "if", as for example if test -f "some_file" do_something fi if [ "$FOO" != "" ] do_something_else fi Schemesh does not have a shell builtin "if", you switch to Scheme for that: (if (file-regular? "some_file') (sh-run {do_something})) Thus the need for "test" and its alias "[" is reduced. Also, "test" implements a mini-language full of one-letter operators: `-f FILE` `COND1 -a COND2` `COND1 -o COND2` etc. I really don't miss it, as I find the equivalent in Scheme to be more readable - and of course more general (file-regular? "FILE") (and COND1 COND2) (or COND1 COND2) etc.
nemoniac 2y ago
> 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!

sshine 2y ago

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 `...`?

cosmos0072 2y ago
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
- sshine 2y ago
  Then [ shadows the sh executable aliased from ‘test’ so that you can no longer do [ some conditional ] && ... But have to write test some conditional && ...
  - cosmos0072 2y ago
    That's true. In shells, "test" and "[" are often used after "if", as for example if test -f "some_file" do_something fi if [ "$FOO" != "" ] do_something_else fi Schemesh does not have a shell builtin "if", you switch to Scheme for that: (if (file-regular? "some_file') (sh-run {do_something})) Thus the need for "test" and its alias "[" is reduced. Also, "test" implements a mini-language full of one-letter operators: `-f FILE` `COND1 -a COND2` `COND1 -o COND2` etc. I really don't miss it, as I find the equivalent in Scheme to be more readable - and of course more general (file-regular? "FILE") (and COND1 COND2) (or COND1 COND2) etc.

nemoniac 2y ago

> 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!