> you could just replace it with… #!/usr/bin/sbcl –load /home/youruser/.sbclrc –script
this doesn't work, since a shebang only accepts one argument.
---
There are 2 main caveats to the described approach: starting SBCL like this from sources and not from a binary takes a little time. And you don’t have batteries included. Want a HTTP client, a CSV parser? You have to quickload them and this adds up in the startup time.
We can rely on long-running images in the editor and run stuff from there, bypassing the terminal altogether, or build binaries, or try other approaches (Lish shell, a lisp server https://notabug.org/quasus/lserver/)
But that’s why I started CIEL, CL with batteries included. You can get a binary and run scripts that start fast and can do common tasks. It’s also a superset of useful libraries that you can quickload or use with a core image (for a fast startup in your editor).
I don’t think that’s right. I regularly use `#!/usr/bin/osascript -l JavaScript` as a shebang on macOS and it works as expected. It’s also good practice to use `/bin/zsh --no-rcs` so the script does not load `~/.zshenv`.
Perhaps this is because osascript can handle '-l JavaScript' as a single arg? The single-arg limitation is a well-known "feature" (ha) of UNIX shebangs.
I feel like I've written this comment a million times but here it is again.
Shell scripts are mainly written in order to automate subprocess-heavy tasks or to take advantage of the general availability of bash or bourne-compatible shells on most modern Unix based systems.
If you want things like reasonable variable scoping, real functions, loops, libraries for path and string manipulation, or a sane separation between what is and isn't a string, then Python is the obvious choice.
Yes, Python's subprocess module is less convenient than doing a subprocess call in Unix shell, but you can replace grep, sed, awk, find, and similar common subprocess calls in shell scripts with library and built-in functions in Python. The end result tends to be more a readable, maintainable, and testable script.
Python 3 also gets installed by default on nearly all non-minimal Linux distros these days. SBCL gets installed by default nowhere.
I use shell scripts left and right for all kinds of things in my regular dev workflow. Running tests with various configurations. Complex tmux layouts. Syncing non-got data. I could go on and on.
Common Lisp would be an incredible asset for this, as Babashka already is in the Clojure world. The REPL alone makes writing/maintaining these scripts very efficient.
Why do you feel like Python must be the choice for everyone?
> Python 3 also gets installed by default on nearly all non-minimal Linux distros these days. SBCL gets installed by default nowhere.
By that rationale we should only use languages which are installed by default on most systems. That's a severe reduction in the number of languages available for people to use.
16 comments
[ 3.0 ms ] story [ 36.5 ms ] threadA first gotcha:
> you could just replace it with… #!/usr/bin/sbcl –load /home/youruser/.sbclrc –script
this doesn't work, since a shebang only accepts one argument.
---
There are 2 main caveats to the described approach: starting SBCL like this from sources and not from a binary takes a little time. And you don’t have batteries included. Want a HTTP client, a CSV parser? You have to quickload them and this adds up in the startup time.
We can rely on long-running images in the editor and run stuff from there, bypassing the terminal altogether, or build binaries, or try other approaches (Lish shell, a lisp server https://notabug.org/quasus/lserver/)
But that’s why I started CIEL, CL with batteries included. You can get a binary and run scripts that start fast and can do common tasks. It’s also a superset of useful libraries that you can quickload or use with a core image (for a fast startup in your editor).
https://github.com/ciel-lang/CIEL/
http://ciel-lang.org/
It’s in beta, polishing phase.
I don’t think that’s right. I regularly use `#!/usr/bin/osascript -l JavaScript` as a shebang on macOS and it works as expected. It’s also good practice to use `/bin/zsh --no-rcs` so the script does not load `~/.zshenv`.
Shell scripts are mainly written in order to automate subprocess-heavy tasks or to take advantage of the general availability of bash or bourne-compatible shells on most modern Unix based systems.
If you want things like reasonable variable scoping, real functions, loops, libraries for path and string manipulation, or a sane separation between what is and isn't a string, then Python is the obvious choice.
Yes, Python's subprocess module is less convenient than doing a subprocess call in Unix shell, but you can replace grep, sed, awk, find, and similar common subprocess calls in shell scripts with library and built-in functions in Python. The end result tends to be more a readable, maintainable, and testable script.
Python 3 also gets installed by default on nearly all non-minimal Linux distros these days. SBCL gets installed by default nowhere.
for this, it's easy to build a binary.
By that rationale we should only use languages which are installed by default on most systems. That's a severe reduction in the number of languages available for people to use.
https://github.com/babashka/babashka