My primary use case for Amber is when I need to write a Bash script but don’t remember the silly syntax. My most recent Bash mistake was misusing test -n and test -z. In Amber, I can just use something == "" or len(something) == 0
I’ve never heard of this before but I’ll make sure to check it out.
It is really neat. I may have to redo all my shell scripts now
tbh, I wouldn’t recommend that during alpha staging. There are still many bugs.
This is an interesting idea and from the looks of it well executed, but I am having trouble imagining a scenario were I would prefer to use Amber over a scripting language like Python. If your bash scripts are getting long enough to warrant the use of Amber you are probably already in a situation where you can justify installing Python.
to some extents - sunk cause fallacy and performance.
I had a launcher script which required it’s run to complete under 50 ms to be usable. python just did not make the cut (it would call external stuff and more). I know i should not expect performancce from shell scripts, but started from essentially a find of about 20-30 files and a cat of at most 100 lines. It was fast enough then. then I kept adding stuff, it kept slowing down. I thought of converting to python, even did some initial bits, performance was not good.
beyond a certain point, i kinda stopped caring optimising (i replaced bash with dash, made mos tif not all calls to external tools a minimum, and tried to minimise slow calls(think calling some tool again and again vs a vectorised operation, or not reading a variable multiple times in memory )). At some point it reached 300-400ms, and i decided to split it into 2 things - a executor part which cahes output of some commands with certain run conditions, and a launcher part which just read the output file (now almost a 1 miB).
At some point i decided learning rust, and first thing i wrote was that launcher. implemented caching and run conditions better, moved larger files (now it read multiple megabytes(15+)) to /tmp dir, which is mounted in memory, and tried to minimise variable calls. now it lists 10 times more files, in less than a third or fifth of the time.
tl;dr - a stupid person did not shift to a compiled program for a long time and kept optimising a shell script
If your program relies too many external tools then I think it makes more sense to use bash than abuse os.system
it’s called
subprocess.run.
I agree, but I can envision scenarios where you are integrating into someone else’s workflow/machine and they (or their build system etc.) are expecting a shell script. Python is ubiquitous but sometimes you just want to work like everything else.
One reason is that Python is not built-in on macOS anymore, so it’s hard to justify using it for management scripts. Particularly when you do not have control of the execution environment to begin with. I’ve written some obnoxiously complicated bash (or zsh) scripts because I want to make sure it will run on a vanilla Mac with no additional dependencies. 10 years ago I would’ve done all that stuff in Python, but not anymore. Thanks, Apple!
From a technical perspective, sure, I could push out a portable python environment and it wouldn’t affect the rest of the system. But that comes at a cost. I don’t want to fight for it, and I don’t want to be responsible for maintaining it. It’s easier to just use bash/zsh.
Python is also too heavy for some embedded devices. Not sure if I can count on Amber scripts to run in a busybox environment but maybe?
That said, if the question is “is it worth learning a whole new thing when I already know bash/zsh”, I am not so sure. But in principle, I dig it, regardless of how practical it is with my specific background and needs. I mean, if I learned about this 20 years ago I feel like I might still be reaping rewards.
I didnt realize it could go to different bash versions.
That could actually be really handy for me, write once and out for the versions I need…
When do you need a newer or older version of Bash to target? I mean usually this is not a thing to concern about.
Client systems outside of my control.
It is not usually a thing to be concerned about. It is something I end up having to be concerned about though.
You have my deepest condolences.
Its an interesting life I suppose.
I don’t like it.
I get why this is useful, and it’s useful for me as well, but the perfectionist in me asks why target bash instead of posix?
Currently, Amber does not even support Bash 2 because Bash 2 does not support the += operator. (ticket) However, I believe that POSIX compliance is on Amber’s long-term milestone, and that it will eventually achieve this as its support range expands.
my guess is mostly lack of arrays in posix shell. there are other things as well, but arrays are really useful, especially when they are making other things easier to write. A stupid comparison i can think of is a compiled language targettng x86-64v2 or 3 instead of v1 because it has avx (i am not actually sure when avx was added, but imagine some instruction being added). without avx, your binary would be slower (in posix, for arrays, you essentially need to maintain a string and use awk/sed/cut to get particular elements, and many things would just not be possible). If they would target v1 (posix), it will run in more places, but it would be slower for a lot of people who have v2 or newer. And a lot of people have v2 or newer (bash).
As someone who knows nothing about POSIX, what’s the difference or in your opinion what would make it specifically better with the context of amber?
I’ve been writing POSIX scripts as a sort of hobby and don’t really have any Bash experience but I think I can still give some insight. Hopefully what I say is accurate but this is what I’ve learned so far.
POSIX is a standard, to say it as simple as possible, it sets the minimum requirements for environment, programs, commands and options for those commands with the purpose of having those commands be as portable as possible. That way a POSIX script will work on any POSIX compliant system. For example a POSIX script could work on Arch, Debian, on a Raspberry Pi or even Mac products. In theory if could work on windows too. If an Operating System ships with a POSIX compliant shell, you are very likely able to run a POSIX script.
Bash is a shell but it has a bunch of features that expand beyond the basic features set by the POSIX standard. Bash also has more features and flexibility for scripting which is why it’s so common to see Bash scripts. Those scripting features are usually referred to as “bashisms.” Since it expands on POSIX scripting, it can look similar to a POSIX script but would not work as intended if you ran a Bash script outside of a Bash shell.
With a lot of modern OS’s, they would likely have Bash installed and you most likely don’t need to worry about anything. However, Bash is not a standard and not required to be installed on every system.
If you care about your script working on as many systems as possible without the worry about what shell is being used, you will probably prefer writing a
shshell, POSIX compliant script.Since POSIX shells and scripts work on a much more basic level, it can lack some depth and finding work arounds for issues can start to look unreadable/insane. A good example is how arrays are handled. POSIX is limited to one array where Bash has much better support for arrays.
There are advantages to using either but with the popularity of Bash, it’s not really that big of a deal in the end.
Interesting. There is this example in the docs:
let result = $ cat file.txt | grep "READY" $ failed { echo "Failed to read the file" }https://docs.amber-lang.com/basic_syntax/commands
How can we know for sure what failed here? Was it the cat or the grep? My instinct says the pipe returns the code of the last cmd or failure, which could be either.
Perhaps it’s just a contrived example and it would be better to separate testing file existence from grepping in real code…
Yep, the code you provided is compiled into this:
command_0="$(cat file.txt | grep "READY")" __status=$? if [ "${__status}" != 0 ]; then echo "Failed to read the file" fiSo, the outcome would depend on the
pipefailoption. (set -o pipefail)As you suggested, an Amberic snippet would be:
import { file_read } from "std/fs" import { match_regex } from "std/text" const result = file_read("file.txt") failed { echo "Failed to read the file" } if match_regex(result, "READY"): echo "file.txt contains READY"
Nice. I find the bash syntax so clunky…
