I have my own scheme-esque language that I use for scripts. 16 of its 48 primitive procedures ~correspond to unix system calls (open, close, read, write, seek, select, stat, link, unlink, mkdir, lsdir, chdir, fork+exec, wait, sleep, exit). It was very instructive to work on, and using something I know inside out is a welcome relief from the uncertainty I feel when intuiting (ba)sh.
Running external programs is a bit more verbose than normal shell, but there is some optional reader-macro sugar on top of fork+exec, e.g. the effect of the following is that /usr/bin/say gets run with those non-string args converted to strings and a voice comes out of my speaker.
IMHO the nicest Scheme for UNIX scripting is scsh. Its APIs are really well thought out and represent a lot of design work that hasn't ever been replicated by another Scheme (at least that I've seen).
Some good examples of scsh scripting (some by the author, Olin Shivers) can be found at
Do you know what is the status of scsh? It's an old project, seemingly unmaintained. Is it considered feature complete? Are there any active users of scsh? What about bugs?
Last time I checked a package for scsh for Fedora was somehow broken and/or conflicting with Chicken and I went with the latter. In general I like the idea and APIs of scsh, I'm just afraid that there will be no one to ask for help if I hit some problems. With Chicken or Racket the communities are active and it's easy to find support. How does this look in case of scsh?
I'm starting to use SBCL for scripting, and on the system with a Lisp on an SSD drive the startup delay is unnoticeable. My friends tell me that on non-SSD setups, adding --script to startup options makes SBCL load almost instantly. It skips various initializations, disables debugger and REPL, and ignores shebang if it's the first line of a script, allowing you to write:
I used Common Lisp from the mid 1980s until about 5 years ago when my customers wanted Clojure, if they wanted Lisp development done. I have never seriously used CL as a scripting language but for a while I was using Gambit-C Scheme for small compiled apps and command line tools. Gambit-C is very good for this purpose.
BTW, Clojure is "out" for command line tools because of the JVM startup time but I have thought about Clojurescript + node.
For even more fun, checkout hy (https://github.com/hylang/hy). It's completely compatible with standard python both ways (ie you can import python from hy and import hy from python), so you can import python-sh and do awesome stuff like:
wget ftp://ftp.gnu.org/pub/gnu/kawa/kawa-2.0.jar
wget ftp://ftp.gnu.org/pub/gnu/kawa/kawa-2.0.jar.sig
gpg --recv-key D269E756
gpg --verify kawa-2.0.jar.sig
echo '(format #t "Hello, world!\n")' > hello.scm
# Not sure how to bundle up a scheme script with kawa
# to a stand-alone jar...
java -jar kawa-2.0.jar --main -C hello.scm
time java -cp kawa-2.0.jar:. hello
Hello, world!
real 0m0.284s
user 0m0.296s
sys 0m0.020s
And, for the record, with the same hello.scm, and guile (2.0.5 as found in Debian stable):
# First run:
time guile hello.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
(...)
Hello, world!
real 0m0.066s
user 0m0.044s
sys 0m0.020s
#Ed: with precompiled code under $HOME/.cache/guile (?)
time guile hello.scm
Hello, world!
real 0m0.040s
user 0m0.036s
sys 0m0.004s
An updated version by Roderic Morris can be installed as a library atop the latest version of Scheme 48. It's on github: https://github.com/scheme/scsh
I think it's 64-bit (?). Most of the time it hasn't mattered for me, at least when writing scripts.
You can also just build the "old" version (0.6.7) with the `-m32` GCC flag, and it works fine on 64-bit Linux and OS X. It's very stable in my experience, and works fine.
I use Kawa Scheme on the JVM for scripting on Windows. Powershell is forbidden where I work. For some reason, it seems to start up faster than Clojure.
I use SBCL for some scripting, and haven't found the overhead to be that bad just using #!/usr/bin/sbcl. For basic stuff, I just use zsh, so by the time I've switched to Lisp, the task is already at the point where startup time isn't a big factor.
I do have some compiled programs I use, but IMO they're a little too big to be called scripts.
An interesting idea would be the ability to dump a shared library of the core image, and then dump incremental changes as executable images that dynamically link to it.
I wonder if the scales would tilt more in favor of separate images if you added a good tree-shaking step. You can bang out useful scripts pretty fast by pulling in a few helper functions from large libraries, but the more scripts share a library, the less functionality you can discard from the final image.
If you can cut the size of the core language's image in half with just a simple method like this, you could probably get impressive results using more sophisticated methods on images requiring a lot of libraries: https://gist.github.com/burtonsamograd/f08f561264ff94391300