Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Lisp Interpreter for Shell Scripting

github.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Show HN: A Lisp Interpreter for Shell Scripting

#21

Post by waynesonfire »

This misses the point of shell scripts.

OUTPUT=$(some_command)

is the killer app of sh scripts among other things, like being universally available. Any language, including this, can execute a command. It's the ergonomics that matter. Shell scripts reduce the impedence of interacting with the shell to control the OS. At first sight, this tool does'nt improve on that impedendance. It also invents it's own esoteric syntax, so what's the gain?

On a separate point but equally important, I don't understand why sh scripts are exempt fom unit tests. Do these tools alleviate that?

Re: Show HN: A Lisp Interpreter for Shell Scripting

#22

Post by esrh »

em-bee wrote: post #15
esrh wrote: post #2

awesome! I have wanted something like this for a long time. Currently I use a janet fork https://github.com/eshrh/matsurika > with some trivial additions, the most important of which is a `$` macro that does what the `sh` does here. I have two questions: - I see that `sh` does not take in strings but instead lisp forms. How do you distinguish between variables that need to be substituted and commands? In my fork, the…

can you give an example of how variable substitution in your language looks like? one of the things i think a lisp for shell should have, and i agree that this may not be easy, but unix commands should be first class functions, as in, you should not need a $ or sh macro to make them work. the other thing is that strings should not be quoted, and so you need something else to designate variables like $path or ($ path)

Yes, i agree that unix commands should be first class. I did this for the super common stuff like ls and cp. As for substitution, I did exactly $ for substitution. You'd do something like ($ rsync -avP $src $dst), but I don't think I ever got around to implementing $() to evaluate forms. If you really need to do that then you have to quasiquote the whole expression and unquote the form you need to evaluate. This has been relatively ok for me though. I never implemented anything like pipes or redirection, I instead just send everything like that to bash.

This is not really relevant to your question, but I regret choosing janet for this, it's too opinionated and hacking on C is not as fun as lisp. I started writing my own version of schemesh in racket, but I never got far enough.

Re: Show HN: A Lisp Interpreter for Shell Scripting

#23

Post by zem »

waynesonfire wrote: post #21

This misses the point of shell scripts. OUTPUT=$(some_command) is the killer app of sh scripts among other things, like being universally available. Any language, including this, can execute a command. It's the ergonomics that matter. Shell scripts reduce the impedence of interacting with the shell to control the OS. At first sight, this tool does'nt improve on that impedendance. It also invents it's own esoteric syn…

this has a `$` - you can do

    (defvar output ($ some_command))

Re: Show HN: A Lisp Interpreter for Shell Scripting

#24

Post by suspended_state »

waynesonfire wrote: post #21

This misses the point of shell scripts. OUTPUT=$(some_command) is the killer app of sh scripts among other things, like being universally available. Any language, including this, can execute a command. It's the ergonomics that matter. Shell scripts reduce the impedence of interacting with the shell to control the OS. At first sight, this tool does'nt improve on that impedendance. It also invents it's own esoteric syn…

> On a separate point but equally important, I don't understand why sh scripts are exempt fom unit tests.

Likely because:

- it's an older culture than unit testing

- people write shell scripts for one shot tasks, or to automate tasks which are system setup/configuration specific

- if a shell script becomes useful enough, it gets rewritten in a more apt language

Post reply on HN