3 ms·
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
by 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 agoThen [ 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 agoThat'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.