search

vito / bass

a low fidelity scripting language for project infrastructure
https://bass-lang.org
MIT License
378 stars 13 forks source link

Evaluating Bass code from stdin #258

Open DrPyser opened 1 year ago

DrPyser commented 1 year ago

Hi, this is a very interesting project which I'm just starting to learn.

One useful pattern of interaction with a script interpreter is to be able to provide script input through stdin.

Currently, when I try to provide input to bass through piping to its stdin, it fails with an error about inappropriate ioctl:

❯ echo '($ echo hello)' | bass
inappropriate ioctl for device

Is it an expected current limitation? Is there currently a way for a bass script to evaluate stdin input as bass expressions? Looking at the reference in the documentation, it seems there is no public API for parsing bass code, or more generally s-expressions. Perhaps this would be exposed through a :bass protocol for read, and the ability to change the protocol associated with the stdin source(currently fixed to json as I understand).

Thanks @vito for this nice work, looking forward to making more use of bass!

vito commented 1 year ago

Hiya, thanks, glad it caught your eye!

Currently, when I try to provide input to bass through piping to its stdin, it fails with an error about inappropriate ioctl:

Good catch, this is probably something that should "just work" as nearly every other scripting language supports it.

I believe right now it's just trying to pop into an interactive REPL because no script was given and failing because stdin isn't a tty. It should instead detect if stdin is a regular file/pipe and just evaluate its io.Reader. I think this would be a pretty minor change somewhere around here:

https://github.com/vito/bass/blob/99973243f585be969e32909669405aaad1948f2c/cmd/bass/main.go#L192

Looking at the reference in the documentation, it seems there is no public API for parsing bass code, or more generally s-expressions. Perhaps this would be exposed through a :bass protocol for read, and the ability to change the protocol associated with the stdin source(currently fixed to json as I understand).

While I'm totally sympathetic to the cause of reading S-exprs as a protocol, I would prefer to decouple that from this issue as it seems slightly different. :slightly_smiling_face: This issue is for native interpretation of Bass code, whereas reading them as data using Bass is something more dynamic. Let's wait until someone has a more precise use case for that.