1. From the docs: "In the the project it is production ready because it is already used in this context because the shell code generated is tested and confirmed that works, the language is evolving with the tooling set."
Hmm...
2. Support Fish too. Having one language that can generate zsh (macOS default), Fish (power users default), and bash would be really nice!
This looks great. We have a lot of bash tools because it's the only stable interpreter that we have readily available on all our systems. But bash is a pain to write so this might actually make things easier.
#!/usr/bin/tcc -run
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello from C!\n");
for (int i = 1; i < argc; ++i)
printf("argument %d: %s\n", i, argv[i]);
return 0;
}
And ready is your cscript :)
$ chmod u+x cscript && ./cscript hello world
Hello from C!
argument 1: hello
argument 2: world
(I can't even articulate why I love it so much that this works)
Obviously it's not a shell script, it's still C. It's fun though and being able to freely specify an interpreter/execution path using a shebang has led me to write some useful little command line utilities in unlikely programming languages over the years. That said, not sure why changing the working directory would be the litmus test. A C program can change its own working directory just as easily as an ordinarily executed bash script?
$ cat bscript.sh && echo "---" && ./bscript.sh
#!/usr/bin/bash
cd testdir/
ls
---
dummyfile
Well, you can "source" a script, so its effects persist in your current shell session. That's a feature of the script and your shell sharing the same language.
Bash is great for orchestrating other Unix tools into an automated workflow. Only when that workflow requires stuff that Bash doesn't have is it time to break out Python. Integrate Shellcheck into your editor, and you get automated help for writing more reliable Bash.
Because it's not preinstalled on every machine. Bash is a good target for portability reasons, but it's a shitty language to write in. If ever I get in the position again to have to write some bash, like for an installer or so, I'm going to be looking into Amber again.
Thank you, but... why not just write in Bash, or the shell you prefer? Why learn a yet another opinionated wrapper?
Yes, Bash or any shell is a very complex and utterly environment dependent language to approach with all due care for security and compatibility, yet hence the lack of wrapper that may not even be aware of these crucial cases at all.
There are other communities where movement in the language came from outside tooling that built extensions on top of the language, such as Sass or TypeScript.
It always comes to be a social problem. Sort of. I want to use X instead of Y, but maybe everyone does not want the same, or adaption of X is harder in technology wise. So I use wrapper Z that compiles to Y, and avoid some problems, but bring new problems. Maybe these problems are smaller ones than just keeping to use Y directly.
bash is really painful to use for anything beyond the most rudimentary logic. Bourne and Mashey were terrible language designers. (By contrast, Thompson's V6 shell is very elegant, if limited.)
That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
> That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
I'm guessing the advantage here would be that the compiled "bytecode" (the resulting bash) can be distributed to systems that would then not need to have Amber installed. (And vs. a real binary from, e.g., Go/Rust/etc., it isn't tied to the platform, either.)
Vs. a Ruby script would require Ruby as a run-time dependency; Amber here is effectively a compile-time dependency.
Python 3 is available basically everywhere these days though, so I think there's still a lot of merit to just using a higher level language like you suggest. Even Ruby, while not available out of the box, is not exactly hard to get on most OSes.
Do we really want to stop evolving the space of languages (and libraries and frameworks while we're at it) just because we have LLM's writing code now? If LLM's were truly smart, they'd argue with us that we should stop asking them to write bash code, because it's a shitty error-prone language. True intelligence should be skeptical of itself and not take any request as a requirement.
1. From the docs: "In the the project it is production ready because it is already used in this context because the shell code generated is tested and confirmed that works, the language is evolving with the tooling set."
Hmm...
2. Support Fish too. Having one language that can generate zsh (macOS default), Fish (power users default), and bash would be really nice!
This looks great. We have a lot of bash tools because it's the only stable interpreter that we have readily available on all our systems. But bash is a pain to write so this might actually make things easier.
How many places do you have Bash, but not AWK?
Or Perl. Or Python. How many environments have only bash and not awk, perl, or python?
Any language is a shell script if you're brave enough: https://en.wikipedia.org/wiki/Shebang_%28Unix%29
Exactly
And ready is your cscript :) (I can't even articulate why I love it so much that this works)Can you change the current working directory? If not, it's not a shell script.
Obviously it's not a shell script, it's still C. It's fun though and being able to freely specify an interpreter/execution path using a shebang has led me to write some useful little command line utilities in unlikely programming languages over the years. That said, not sure why changing the working directory would be the litmus test. A C program can change its own working directory just as easily as an ordinarily executed bash script?
in C you can change dir easily via `chdir()`[1] [1] https://www.man7.org/linux/man-pages/man2/chdir.2.htmlIf you meant somehow changing the parent shell's directory an ordinary bash script doesn't do that either
Presumably you can call chdir(2) from the C code?
Or did you mean change the directory of the calling shell (in which case, executable shell scripts written in Bash and friends can’t do that either).
Well, you can "source" a script, so its effects persist in your current shell session. That's a feature of the script and your shell sharing the same language.
> Typescript to bash
Literally the worst of both worlds.
Bash is great for orchestrating other Unix tools into an automated workflow. Only when that workflow requires stuff that Bash doesn't have is it time to break out Python. Integrate Shellcheck into your editor, and you get automated help for writing more reliable Bash.
bash bashing i can understand. whats wrong with ts tho?
I'm a fan of this project. Great work!
Just wanted to say that I think you did a great job with your examples showing why someone might be interested in this language.
unclear use case imo - this sacrifices the ergonomics of actual bash scripting, and hides it behind another language
If your script is complex enough to need a higher level language you might as well just switch to python
bash scripting has ergonomics?
Much needed. I have hard time understanding bash.
Hm... But why not use Python
Because it's not preinstalled on every machine. Bash is a good target for portability reasons, but it's a shitty language to write in. If ever I get in the position again to have to write some bash, like for an installer or so, I'm going to be looking into Amber again.
I’ll give it a shot.
Side note: the image of project founder cosplaying as Steve Jobs on front page had me dying.
I clicked the link to see this image and wasn't disappointed. It's fantastic!
Another alternative for writing Bash is Babashka, which is a Clojure dialect.
Thank you, but... why not just write in Bash, or the shell you prefer? Why learn a yet another opinionated wrapper?
Yes, Bash or any shell is a very complex and utterly environment dependent language to approach with all due care for security and compatibility, yet hence the lack of wrapper that may not even be aware of these crucial cases at all.
Your argument is down to the weights.
There are other communities where movement in the language came from outside tooling that built extensions on top of the language, such as Sass or TypeScript.
It always comes to be a social problem. Sort of. I want to use X instead of Y, but maybe everyone does not want the same, or adaption of X is harder in technology wise. So I use wrapper Z that compiles to Y, and avoid some problems, but bring new problems. Maybe these problems are smaller ones than just keeping to use Y directly.
bash is really painful to use for anything beyond the most rudimentary logic. Bourne and Mashey were terrible language designers. (By contrast, Thompson's V6 shell is very elegant, if limited.)
That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
> That said, this should just be a shell itself and not something that generates into other shell dialects. Otherwise, why not use Ruby or something like it that has actual expressive power?
I'm guessing the advantage here would be that the compiled "bytecode" (the resulting bash) can be distributed to systems that would then not need to have Amber installed. (And vs. a real binary from, e.g., Go/Rust/etc., it isn't tied to the platform, either.)
Vs. a Ruby script would require Ruby as a run-time dependency; Amber here is effectively a compile-time dependency.
Python 3 is available basically everywhere these days though, so I think there's still a lot of merit to just using a higher level language like you suggest. Even Ruby, while not available out of the box, is not exactly hard to get on most OSes.
Hot take, but Powershell is quite an elegant shell language. It's actually a lot easier to write than Bash.
It took my quite a while to get used to all the verbose method names, but it actually makes it pretty readable by default.
If you don't want to use it, don't use it
In a world where AI can generate any code for any environment, is there a need for another language?
On the other hand, we're at a point for a binary language (or standard / framework) that one AI/LLM creates and another one validates.
What are we missing?
Do we really want to stop evolving the space of languages (and libraries and frameworks while we're at it) just because we have LLM's writing code now? If LLM's were truly smart, they'd argue with us that we should stop asking them to write bash code, because it's a shitty error-prone language. True intelligence should be skeptical of itself and not take any request as a requirement.
We're missing AI that doesn't still its hand held every step of the way.