

Scsh – Scheme as a Unix shell - michaelsbradley
http://scsh.net/about/what.html

======
saidajigumi
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
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
"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/](https://github.com/amoffat/sh/)

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

[3] [https://github.com/polydawn/josh/](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
The grandaddy of all of those is probably the
[http://perldoc.perl.org/Shell.html](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.

~~~
kjs3
I can't imagine why you'd think that. SCSH predates Perl Shell (1993 v.
1994?), and things like CLASH are almost as old. GNU Emacs has been usable for
a login shell for almost that long, as I recall.

~~~
simcop2387
I meant the modules that were talked about in the parent comment. Not as a
predecessor to scsh. The Perl module I referenced isn't to use Perl as a shell
and neither are the modules mentioned by heavenlyhash. They instead allow one
to use system commands as if they were previously declared functions. While
scsh and clash both do this to allow you to use it as an interactive shell
they do not extend the parent language (as far as I can see) to be used like a
shell scripting replacement. Emacs is a slightly different case as im not sure
where the line between elisp and emacs should be drawn. If yiliu look at the
modules in the other comments you'll see they all have roughly the same
interface as the Perl module from 1994, before many of the languages, python,
go, java existed or were really used by then.

~~~
kjs3
If "allow one to use system commands as if they were previously declared
functions" is your criteria, then things like Symbolics Genera, PERQ POS and
Xerox Star/Alto predate it by even more. This is not a new or original idea to
Perl.

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

~~~
th0ma5
The documentation seems to suggest it supports through a library a "rec" as in
recursive command as documented here
[http://srfi.schemers.org/srfi-31/srfi-31.html](http://srfi.schemers.org/srfi-31/srfi-31.html)
... not sure how to extrapolate that to your specific example however :D

------
rml
Emacs users who want to play around with scsh might like:

* Geiser integration that (mostly!) works: [https://github.com/rmloveland/geiser-scsh](https://github.com/rmloveland/geiser-scsh)

* The manual in Texinfo format: [https://github.com/rmloveland/scsh-manual-texinfo](https://github.com/rmloveland/scsh-manual-texinfo)

------
antocv
That example looked like it would be hell to write from the tip of the tounge.

~~~
leoc
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.

