Is there a way to customize the SBCL REPL in a way that makes it work similar to the CLISP REPL. The standard SBCL REPL isn't really usable on Mac OS X. I can't use the arrow keys or backspace.
You could use rlwrap
If you have MacPorts installed you can get it with
sudo port install rlwrap
The invoke sbcl with
rlwrap sbcl
Most of the people use SBCL REPL with SLIME. It gives it by far much more features, then readline, that is used in CLISP. If you aren't comfortable with using Emacs, you can try ABLE (available through quicklisp) - a very simple editor, that supports some basic REPL features on par with readline, but as well has basic code highlighting and built-in Hyperspec.
There's vim+slime (slimv) too, for vim users.
You can try linedit which is available via Quicklisp. That said, Emacs+SLIME is a real beast. In fact, Firebug is the only thing close to it that I'm aware of.
Related
I've had trouble using Julia in Windows Terminal for the last few releases because the ANSI escapes refuse to render properly unless I enable Legacy Console Mode which helps in CMD prompts, but not in Windows Terminal.
When launched in Terminal, it looks like this:
When launched with --color=no, it looks like this:
Which is marginally more useful, but both the inputs and outputs are muddled by the ANSI escapes, which makes the REPL effectively useless.
My workaround has been to enable the "Legacy Console" and use an alias to launch julia in a separate CMD-based window when I need REPL functionality, but this is disruptive.
I have tried various combinations of (multiple releases of) Windows Terminal (stable and dev), Powershell (stable and dev), and Legacy Console mode. There must be a configuration issue on my machine that I just can't nail down because no one else seems to have this issue.
What am I missing?
Can you file this over at https://github.com/microsoft/terminal/issues?
By all accounts, this should work. Seeing the literal escapes in the buffer like that makes me think that Julia isn't enabling ENABLE_VIRTUAL_TERMINAL_PROCESSING, which they would need for escape sequences to work. Though, if you're on a version of julia from 2021, I would presume that they're aware of that and would be setting that mode by now. (That flag was added in like, 2016)
Hopefully we can help diagnose more over at the Terminal repo ☺️
Start to learn Julia recently. And do not want to use console ever.
How can I install a new package from IDE, with no use of console commands? I'm using Juno, but I'm opened to change IDE if Juno does not support such a feature. Than the question is - what IDE does?
You can evaluate commands from a script. Just type Pkg.add into a script and Ctrl+Enter on it. But I don't think avoiding the console entirely is a good way to program though!
Write a script
Pkg.add("Distributions")
and run it.
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.
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.
I've already got slime+emacs+sbcl running (SBCL 1.0.23) on my Windows XP machine. CUSP installs with SBCL 1.0.6.
Is there a way to make CUSP use the existing SBCL installation instead of its own?
You can, I don't have it installed on this computer; but in the options (maybe preferences) section (where Java, Lisp, and other tabbed panels to the left are listed) there is a sub section under Lisp called implementation.
In that section you can select which SBCL binary to use and which image file to load. It doesn't work with the latest SBCL implementation (At least as far as I know).