top | item 8257936

Scsh – Scheme as a Unix shell

54 points| michaelsbradley | 11 years ago |scsh.net | reply

18 comments

order
[+] saidajigumi|11 years ago|reply
This is certainly an interesting use of Scheme macros for a shell-like DSL. For a long time I've mused over ideas for a Unix-ish shell that embeds first-class access to a richer scripting language than typical shell scripting. In this light, Scsh is similar to many other projects I've seen over the years in various languages, in that its effective aim is more about shell-like scripting in an alternate language.

For my goals where all of these attempts fall down, including Scsh, is in the syntax. One of the best aspects of working in the various Unix shells is their very low syntactic ceremony. I find that even similar "shell nouveau" attempts in Ruby are cumbersome, despite that language having relatively low syntactic ceremony for a full programming language. E.g. I don't want to have to write even one function/method call just to run a program. That's far too heavyweight for a user shell, even when the least it adds are a pair of parens.

For a new shell that I'd actually want to use, there seem to be two key criteria:

1. There needs to be a radically low-ceremony user interface that respects everything we've learned from Unix shells over the years. Perhaps it's best to think of this UI as its own DSL inspired by a subset of existing shell UI. This includes staples such as pipeline composability, etc. Ironically, the best new-generation examples of this principle seem to be GUI launcher tools like Quicksilver and its conceptual offspring. While far from being Unix shells, they can be seen as a wonderful generalization/simplification of the essential shell "<thing> <modifiers>" + completion UI.

2. A seamless way to enter "write real code" mode, where the focus of "real code" is on shell power-user workflows and customizing and extending shell functionality. I'm not interested in making this into yet another standalone scripting tool, since there are a plethora of choices for modern languages that cover this ground. E.g. if one uses a shell backed by a mature language such as Scheme/Ruby/Python/etc. then the normal runtimes for those languages can support standalone scripting use. As needed, useful idioms developed in the shell environment could easily be exported as a library for use in standalone scripts. (And again, I think Scsh's shell-like macros are a great example of that.)

[+] readstoomuch|11 years ago|reply
I think Emacs eshell hits the sweet spot with this. Behaves like a normal shell for common tasks, with the ability to drop down to S-exprs if need be.
[+] heavenlyhash|11 years ago|reply
"sh" [1] by amoffat did something similar to this in python. It's so marvelous I've also ported the same ideas to "gosh" [2] for use in golang and "josh" [3] for use in java. There's probably others as well -- I'd love to hear about more options in other languages.

[1] https://github.com/amoffat/sh/

[2] https://github.com/polydawn/pogo/blob/master/gosh-demo.go

[3] https://github.com/polydawn/josh/

(The golang implementation is probably my favorite of these, since pipelining the output is by far the most pleasant experience there, and channels actually provide parallelism in a similar way what one expects from unix pipes. I'll admit I haven't benchmarked, but I suspect pipelining a lot of information in the python one is going to encounter the GIL; and as for the java one, well, let's just say I'd like to have a word with the authors of the current java subprocess invocation APIs.)

[+] simcop2387|11 years ago|reply
The grandaddy of all of those is probably the http://perldoc.perl.org/Shell.html module in Perl. The idea is really nice for a lot small scripts but can seem to hide some magic because you're treating commands as functions.
[+] saidajigumi|11 years ago|reply
Fantastic and new to me, thanks. I love amoffat's approach to creating a Python DSL for command-line app interaction.
[+] brandonbloom|11 years ago|reply
I love sexprs. In fact, I generally prefer prefix notation with the extra parens. However, for such a high frequency interactive use case, it really does meet the cost/benefit requirements to have specialized syntax...
[+] jrapdx3|11 years ago|reply
I'm quite familiar with Scheme and can do useful things with it. Not so sure how comfortable it would be to have Scheme on the command line.

Maybe it's just a matter of getting used to s-expr in that context, but after a few decades learning the classic command-line syntax, making that change could be hard.

OTOH the ability to use low level OS functions at the shell prompt or in a script might compensate for the trouble. Giving it a try would be the only way to find out. I might just do that and see what happens.

[+] simcop2387|11 years ago|reply
I'd love to see something a bit less trivial, like iterating over the output of another command to run some other commands

    for i in `bin/hosts`; do ssh $i uptime; done
[+] rml|11 years ago|reply
There might be a better way, but this should work:

    (for-each (lambda (x)
            (run (ssh ,x uptime)))
          (run/strings (cat /etc/hosts)))
[+] antocv|11 years ago|reply
That example looked like it would be hell to write from the tip of the tounge.
[+] leoc|11 years ago|reply
Nah, it shouldn't be hard once you're used to (fun a b) syntax. So what would be pipe(cmd1(), cmd2()) in an algolic syntax is instead (pipe (cmd1) (cmd2)) and so on from there.