The title pretty much says it all. I use clojure for my major projects but it's not a good scripting language because the jvm has a slow startup and doesn't interface well with some unixy things. So I'm looking for a lisp which will work well as a scripting language, for example having a good interface for managing unix processes, easily use things like async io, etc.
Scsh (it stands for "Scheme shell") can be gotten at http://www.scsh.net. It's "a variant of Scheme 48 (an R5RS compliant new-tech Scheme system) ... designed for writing real-life standalone Unix programs and shell scripts."
A nice introduction to system administration in it can be found at http://www.theillien.com/Sys_Admin_v12/html/v11/i01/a2.htm.
A wide range of common unix tools have bindings for Guile. If its your objective to automate any of these tools, this might be a nice place to look.
Racket is a really nice Scheme implementation. Its pretty powerful. One of its introductions is developing a web server from scratch.
Scsh
newLisp
PicoLisp (also see this)
CLISP, an implementation of Common Lisp, is useful for Unix scripting.
CLISP has many extensions that make it useful for scripting: Unicode support, regular expressions, various command line options, socket streams, piping, ...
Additionally CLISP has a relatively small footprint, is written in C for portability and starts fast - for a Common Lisp.
Eshell with Elisp for interactive use:
"Eshell is capable of invoking almost any elisp function loaded in Emacs. That sort of flexibility is unmatched; there are no shells out there capable of approximating what Eshell can do. In fact, this functionality is heavily used (and encouraged!) by Eshell. If you want to open the file foobar.txt in Emacs you simply invoke find-file foobar.txt and Eshell will map that to the elisp call (find-file "foobar.txt") and open the file for you."
from http://www.masteringemacs.org/articles/2010/12/13/complete-guide-mastering-eshell/
I ran into this page a few times while looking for a nice way to port some increasingly-unweildy bash scripts into a saner language. Since these scripts were already invoking a few Racket scripts, it made sense to remove a layer of indirection and use Racket for everything.
After some searching, I came across the shell-pipeline package for Racket. From the documentation:
This library makes unix-style pipelines of external programs and racket functions easy. You can write things as simply as (run-pipeline '(cat /etc/passwd) '(grep root) '(cut -d : -f 1)), which will print "root\n" to stdout (on unix systems) and will return 0. To get the output as a string, use run-pipeline/out the same way. You can also put racket functions in the pipeline. If you have a racket implementation of grep called my-grep, you can do (run-pipeline '(cat /etc/passwd) `(,my-grep root) '(cut -d : -f 1)) to get the same results. So you can write all sorts of filter functions in Racket rather than using shell commands.
Related
I'm new to working with Coq, and I'm progressing through the first volume of the Software Foundations book, but I can't for the life of me figure out how to compile the Basics.v file for the second chapter on induction.
I've seen things floating around about using the Coqc command on the command line, but I don't know how to access the terminal, or at least the windows terminal doesn't recognize the command. If anyone could walk me through this it'd be much appreciated!
In case you are using CoqIDE, there is a menu item "Compile/Compile buffer", which creates a .vo file for the currently loaded .v file. For a few files and early stages of learning, this might be the easiest way.
Then SF likely comes with a make file which you can just run with make. You didn't say what OS your are using - on Linux and Mac this should be trivial, on Windows it depends on how you did install Coq. The Windows installer doesn't come with make, but if you used the Coq Platform scripts to setup Coq on Windows, everything is there.
Otherwise it might get a bit complicated - you need to pass the right options to coqc (which CoqIDE and make do automatically for you).
I am new to Common Lisp. This is how I develop programs in other languages, and also how I now develop programs in Common Lisp:
Open a text editor (e.g. vim or emacs) to create/edit a text file.
Write source code into the text file. (If unsure about the behavior of a snippet of code, and an REPL is available, then evaluate the snippet in the REPL, verify that the snippet evaluates as expected, and then go back to writing more code.)
Save the text file.
Ask the compiler/interpreter to load and run the source code in the text file. (e.g. sbcl --script myprog.lisp)
Go to step 1 if needed.
This is the conventional write-compile-run development cycle for most programming languages. However, in the lisp world, I hear things like "interactive development" and "image-based development", and I feel that I am missing out on an important feature of Common Lisp. How do I do "image-based development" instead of "write-compile-run development"?
Can someone provide a step-by-step example of "image-based development" similar to how I described "write-compile-run development" above?
(Note: I am using SBCL)
In typical Common Lisp implementations the runtime, the compiler, parts of the development environment and the program you are developing reside in the same program and share the same object space. The compiler is always available while you develop the program and the program can be incrementally developed. The development tools have access to all objects and can inspect their state. One can also undefine/remove, replace, enhance functionality from the running program.
Thus:
don't restart the program you are developing. Stay connected and update it. Even days, weeks, or months - if possible.
write code in such a way that the program can be replicated and built from scratch if necessary. Build it from time to time and fix any build problems.
once you use our program and there is an error -> fix the error within the program, while being able to inspect the full error state
creating a running program is either loading all code into a plain Lisp all the time or saving an executable image with the loaded code/data
Fixes to program bugs can also shipped to the user as compiled Lisp files, which gets loaded into the delivered program and update the code then.
Let's say that you are using SBCL with Emacs and SLIME (e. g. through Portacle).
Open Emacs
Start SLIME (M-x slime) — this starts a “plain” Lisp process in the background and connects the editor functions provided by slime to it; then gives you a REPL that is also connected into this process (image)
Open a text file (e. g. foo.lisp)
Type some code
Press C-c C-k to compile the file and load it into the running Lisp process
Switch to the REPL, try it out
Switch to the Lisp file (step 4).
This is just very basic usage. Further things to do/learn
You can also compile and load just a single toplevel form (C-c C-c)
Learn about packages
Learn about systems (ASDF)
Learn how to use Quicklisp to get the libraries you want
Learn how to access inline documentation from the REPL
Note that you never need to unload your program, you just modify it, even when downloading and loading new libraries. This makes the feedback cycle instantaneous in most cases. You also never need to switch away from the IDE (Emacs).
I am wondering if it is somehow possible to have an OSGi environment with GoGo shell running with different consoles for input and output.
It is not very handy to write gogo commands into a console where your system is logging a lot of data.
Is there a good solution for that?
There are a number of solutions for your question.
You can use the telnet or ssh interface to gogo. Apache Felix provides both in separate bundles.
Gogo registers a CommandProcessor from which you can make a CommandSession by supplying an Input and Output Stream. It is quite easy to make a small Java Swing program that acts as a shell
Stop logging so much :-)
We are using RDI (IBM Rational Developer for System i) to do cobol development work, we are eager to write automation test cases for our program, to make the testing work easier. But we don't know how to use script to compile and run cobol, which on i-series server.
For now, our solution is that we use scripts prepare test data (insert data to database/files),and then run cobol on RDI manually, finally, run scripts to check the results. It makes our work easier, but still not real automation test.
So, I want to know if there are some methods to invoke the compile&run process according to scripts, such eclipse headless or telnet technologies.
We've already found the solution: use telnet to compile/run program. Because green screen is one kind of telnet, it reliable.
Can anyone please let me know the coding guidelines along with code samples of Unix shell scripting by using which the code can run on most of the current shells like ksh, bash, csh etc. Most of the times some of my code written for ksh would not work on normal sh. I want to make my code maximum portable. Most of my code will be around [ifs, elifs] and [whiles, fors] and return code capturing of child shell (which will mostly be running SQL scripts for which I want to get some of the return codes like number of rows processed, return codes, error codes of the SQL script).
Also can anyone let me know which shell specific code can be easily ported to other shells? Can anyone point me to right tutorials and/or sample codes?
Get yourself a 7th Edition Unix Programmer's Manual (Vol 1) and program to the (Bourne) shell notation described there. You can actually upgrade to a System V (Bourne) shell if you can find an appropriate manual; it has a few extra features, like functions, that the 7th Edition shell did not have, and they are essentially available everywhere. (This is a very conservative stance - but it will give you maximal portability.)
The other issue is choosing which commands you use, and which options you use to those commands. For example, GNU grep has numerous useful options that are not available elsewhere. GNU sed similarly has extensions that are not available elsewhere. If you write your shell script to use those extensions, your code will be unportable, even if the shells all understand the syntax correctly.
I recommend being aware of what the POSIX standard says is portable. Most of the POSIX features are usually supported by most systems, but each system usually adds some extra options and features that are not always widely available. Note that the POSIX shell does have some features, notably $(...) command substitution in place of back-ticks that you were not in original Bourne shells. You'll have to decide whether the clarity that the more modern notation brings is worth the (nominal) loss of portability.
Also, the Autoconf shell guidelines concentrate on maximal portability. However, the result is a rather stilted version of shell scripting, not least because it has to interwork with the m4 macro processor, which leads to some additional constraints.
Note that it is essentially impossible to write portable shell scripts that will work with the Bourne/Korn/POSIX shell family and the C Shell family. There are strong arguments for concluding "you should not write scripts in C shell".
The short answer for portability is to write scripts for the lowest common denominator which is the Bourne shell (sh) and to avoid C shell which has an incompatible syntax and serious limitations. The Bourne shell should be universally available and most system startup and administration scripts are written for it.
All of the capabilities you mentioned as requirements are available in sh. One of the main things that is missing is support for arrays, but that can be worked around.
One thing to keep in mind is that much of the functionality of a shell script is provided by external utilities which are accessible from any shell.
why not write your scripts in perl or python?
Get yourself Beginning Portable Shell scripting and see what the author have to say.
There's some portability talk between shells in Bash Hackers Wiki. See, if that helps.
There's also Steve Parker's Bourne / Bash online shell scripting tutorial or books such as "Shell Scripting Recipes: A Problem-Solution Approach" by Chris F.A. Johnson.
To test for maximum portability you may use bournesh.
http://freshmeat.net/projects/bournesh/
I've a few links from here:
http://www.pixelbeat.org/programming/shell_script_mistakes.html#portability
You can use Loker for checking for syntactic conformance to the POSIX standard.