The superpower of shell scripting languages is not just that it's easy to run external processes, it's also that you can run them extremely flexibly: chain them into pipelines, run them in background, redirecting streams, process substitution, etc. These kinds of things is why "just use Python or whatever!" is not always a great answer to "shell scripting sucks" (which it does, I agree). I mean, you CAN do all those things in Python, but it's a huge pain in the ass to write compared to the dedicated syntax of shell scripting.
If the developers of ABS are reading this, it would be great some examples of that kind of thing to the homepage. Like, how would you do `curl <url> | grep something | sort | uniq | tee output.txt`? What about process substitution? What about redirecting stderr to stdout? And, the biggest problem with shell scripting is escaping problems, how does ABS handle that? Can you run a command with an array of strings as argument instead of having the shell split on (unescaped and unquoted) spaces?
They are also much more interaction based than people typically ack. Ctrl-z sending something to the background and being able to list the currently active jobs for the current shell are specifically affordances for someone sitting at the keyboard. Even the pushd/popd workflow is again for the operator.
Python and a few others such as LISP, smalltalk, etc., have some affordances made for a developer at the keyboard. Oddly, most of them are not taught to developers, it seems. The number of people I have worked with that didn't know of python's `help` is stark.
I remember someone made an interesting point that the notable thing about traditional shell scripting languages (as opposed to conventional scripting languages) is that the filesystem is effectively the "top level scope" of the language. i.e. you can refer to files (paths) much like they are variables that are ambiently defined.
Yeah, and environment variables as well. It's notable that the syntax for reading an environment variable in bash is identical to the syntax for reading a "normal", process local variable (though setting is slightly different, you have to use "export"). It's like the ground scope is "the computing environment" (files, processes, env vars, ...), not the "program sandbox".
> it's also that you can run them extremely flexibly: chain them into pipelines, run them in background, redirecting streams
Imho traditional shells are actually pretty limited in this regard; you generally can only compose programs in simple linear pipelines with one input one output. Technically bash does allow doing some stuff with additional fds, but it is not very convenient nor flexible in that regard. There have been some attempts to make more flexible shells, like for example dgsh: https://www2.dmst.aueb.gr/dds/sw/dgsh/
You can do that by using mkfifo relatively easy, but I take your point. In that sense, the most "flexible" language is pure C, because you can do anything there. I guess a better word is "ergonomic": if you want to do `curl something | grep whatever > output.txt` in C or Python or whatever other general purpose language, it's MUCH more difficult. Writing lines like that is trivial for me in shell scripting, I just did it in this comment. If I had to do it in Python, I would have to spend 20 minutes studying the precise flags to pass to subprocess.Popen and think really hard about which streams to call .close() on and when. God help me if I was doing it in C and using fork()/exec().
This is the shell scripting super-power, all this stuff is just trivial.
Which is the common case, for which it does a reasonable job. I think if I was looking at most of the directed graph examples, I'd look to another tool than a shell to orchestrate that, rather than say "you know what my shell lacks? More special case syntax.".
I think a common strategy (at least for me) is to make good use of Linux commands and things like Awk and Sed. If it grows more than a few lines, it's often best to switch to something like Python, Perl, Tcl...etc.
That's a (self-)discipline thing. One has to do something about "this script has become a big conky" other than default to "oh, what's another 10 lines". Which we all do.
At some point, the clear features of modern languages far outweigh what I get out of the command line tools and Awk/Bash. For me, it doesn't take long, so it's less discipline and more not wasting my time. Your mileage may vary though.
That's a major reason that https://oils.pub/ started out with the POSIX- and bash-compatible OSH, and then added YSH on top of it (while removing legacy)
But YSH is the only one that has a process runtime that's a SUPERSET of bash
---
I also want to add to add xargs-like functionality to the runtime. I mentioned in the latest release that bash/xargs actually has a problem with waiting for processes in parallel, while ALSO checking for errors:
"joy of shell scripting" feels like something only someone who has never done any shell scripting would say. Shell is a horrendous excuse for a programming language that is truly one of the hardest things to deliver working software in.
What's the rationale? We have many well established cross-platform shell languages, like PowerShell, Perl, Python, AWK. What does ABS do better than them?
Not sure I like `command` failing silently, i.e. having to remember to check the .ok property. Most guidelines for writing sh/bash scripts arrive at using "set -e" mode unless you have a good reason not to. So when designing a new language, why not flip the default?
Personal nitpick, but whenever I see a project trying to promote itself by actively bashing (no pun intended) the current solution in its tagline, no-matter how catchy the tagline, my gut feeling is to avoid it without spending much time to evaluate the offering.
I'm much more receptive to projects telling me how they're good, rather than how the competitor is bad.
I can understand that but these are open source projects and the author might have valid feelings if he wants to bring back the joy of shell scripting because maybe that's why he created yet another shell scripting language...
I can definitely understand both points of view but my pov is that we shouldn't avoid projects solely because of these and that there are greater merits to choose from. We are more similar than different :) in foss community I suppose
Another thing is that sometimes, people don't like taglines telling how good the project is, like I searched fish and I love fish but fish is a smart and user-friendly command line shell for Linux, macOS, and the rest of the family.
Maybe its me as I could only vouch for the user friendly part of fish from my small time using it (and the time I mimicked every aspect of fish for my zsh config file). I truly loved fish but I might not be sure about its smartness and what it means by that and that might be a nitpick but I still love fish and would recommend it to some people
Maybe I can be wrong, I usually am and someone please feel free to correct me to make me understand what they mean by smart, I know that somethings scripting in fish can be more pleasant than bash and it has some nice features but just smart is really vague, I hope everybody gets it :)
Seriously though, this actually doesn't look half bad. The problem is you can easily achieve the same thing in basically any standard scripting language (Typescript, Python, etc.) just by replacing backticks with a function call.
Actually in Typescript you can use tagged string so it could just be one extra character if you want:
let result = x`ls -l`;
Is saving that one character worth using a niche language?
I agree, it's a cool idea but I actually think the lack of mantainability of shell languages are a coincidental feature not a bug, making sure that once you hit a certain complexity you're forced to switch to a full programming language.
The superpower of shell scripting languages is not just that it's easy to run external processes, it's also that you can run them extremely flexibly: chain them into pipelines, run them in background, redirecting streams, process substitution, etc. These kinds of things is why "just use Python or whatever!" is not always a great answer to "shell scripting sucks" (which it does, I agree). I mean, you CAN do all those things in Python, but it's a huge pain in the ass to write compared to the dedicated syntax of shell scripting.
If the developers of ABS are reading this, it would be great some examples of that kind of thing to the homepage. Like, how would you do `curl <url> | grep something | sort | uniq | tee output.txt`? What about process substitution? What about redirecting stderr to stdout? And, the biggest problem with shell scripting is escaping problems, how does ABS handle that? Can you run a command with an array of strings as argument instead of having the shell split on (unescaped and unquoted) spaces?
They are also much more interaction based than people typically ack. Ctrl-z sending something to the background and being able to list the currently active jobs for the current shell are specifically affordances for someone sitting at the keyboard. Even the pushd/popd workflow is again for the operator.
Python and a few others such as LISP, smalltalk, etc., have some affordances made for a developer at the keyboard. Oddly, most of them are not taught to developers, it seems. The number of people I have worked with that didn't know of python's `help` is stark.
I remember someone made an interesting point that the notable thing about traditional shell scripting languages (as opposed to conventional scripting languages) is that the filesystem is effectively the "top level scope" of the language. i.e. you can refer to files (paths) much like they are variables that are ambiently defined.
Yeah, and environment variables as well. It's notable that the syntax for reading an environment variable in bash is identical to the syntax for reading a "normal", process local variable (though setting is slightly different, you have to use "export"). It's like the ground scope is "the computing environment" (files, processes, env vars, ...), not the "program sandbox".
Agreed.
Then again nothing stops a general-purpose language from providing a built-in syntax & data type for paths, see e.g. Nix.
> it's also that you can run them extremely flexibly: chain them into pipelines, run them in background, redirecting streams
Imho traditional shells are actually pretty limited in this regard; you generally can only compose programs in simple linear pipelines with one input one output. Technically bash does allow doing some stuff with additional fds, but it is not very convenient nor flexible in that regard. There have been some attempts to make more flexible shells, like for example dgsh: https://www2.dmst.aueb.gr/dds/sw/dgsh/
You can do that by using mkfifo relatively easy, but I take your point. In that sense, the most "flexible" language is pure C, because you can do anything there. I guess a better word is "ergonomic": if you want to do `curl something | grep whatever > output.txt` in C or Python or whatever other general purpose language, it's MUCH more difficult. Writing lines like that is trivial for me in shell scripting, I just did it in this comment. If I had to do it in Python, I would have to spend 20 minutes studying the precise flags to pass to subprocess.Popen and think really hard about which streams to call .close() on and when. God help me if I was doing it in C and using fork()/exec().
This is the shell scripting super-power, all this stuff is just trivial.
simple linear pipelines
Which is the common case, for which it does a reasonable job. I think if I was looking at most of the directed graph examples, I'd look to another tool than a shell to orchestrate that, rather than say "you know what my shell lacks? More special case syntax.".
Sure, sh might be fit for it's purpose, but I wouldn't call it "extremely flexible"
I think a common strategy (at least for me) is to make good use of Linux commands and things like Awk and Sed. If it grows more than a few lines, it's often best to switch to something like Python, Perl, Tcl...etc.
That's a (self-)discipline thing. One has to do something about "this script has become a big conky" other than default to "oh, what's another 10 lines". Which we all do.
At some point, the clear features of modern languages far outweigh what I get out of the command line tools and Awk/Bash. For me, it doesn't take long, so it's less discipline and more not wasting my time. Your mileage may vary though.
It seems that some kind of piping is possible: https://github.com/abs-lang/abs/blob/master/examples/pipe.ab...
That's a major reason that https://oils.pub/ started out with the POSIX- and bash-compatible OSH, and then added YSH on top of it (while removing legacy)
In YSH, you can do everything that bash does with processes, because OSH is the most bash-compatible shell in the world: https://pages.oils.pub/spec-compat/2025-09-14/renamed-tmp/sp...
For example, I think many of the newer shells don't implement process subs, a ksh/bash thing:
YSH also improves on bash by checking the error code from process subs, which bash simply ignores: BUT you can also do Python like stuff, pretty much exactly like ABS's example on the home page (hm I wonder if str(n) should be relaxed ...)ABS is listed on this wiki page, along with many Python- and JavaScript- influenced shells:
https://github.com/oils-for-unix/oils/wiki/Alternative-Shell...
https://koi-lang.dev/
https://github.com/alexst07/shell-plus-plus
https://hush-shell.github.io/
But YSH is the only one that has a process runtime that's a SUPERSET of bash
---
I also want to add to add xargs-like functionality to the runtime. I mentioned in the latest release that bash/xargs actually has a problem with waiting for processes in parallel, while ALSO checking for errors:
Eight Releases of Oils in 6 Months: https://oils.pub/blog/2025/09/releases.html
"joy of shell scripting" feels like something only someone who has never done any shell scripting would say. Shell is a horrendous excuse for a programming language that is truly one of the hardest things to deliver working software in.
What's the rationale? We have many well established cross-platform shell languages, like PowerShell, Perl, Python, AWK. What does ABS do better than them?
Not sure I like `command` failing silently, i.e. having to remember to check the .ok property. Most guidelines for writing sh/bash scripts arrive at using "set -e" mode unless you have a good reason not to. So when designing a new language, why not flip the default?
Personal nitpick, but whenever I see a project trying to promote itself by actively bashing (no pun intended) the current solution in its tagline, no-matter how catchy the tagline, my gut feeling is to avoid it without spending much time to evaluate the offering.
I'm much more receptive to projects telling me how they're good, rather than how the competitor is bad.
I can understand that but these are open source projects and the author might have valid feelings if he wants to bring back the joy of shell scripting because maybe that's why he created yet another shell scripting language...
I can definitely understand both points of view but my pov is that we shouldn't avoid projects solely because of these and that there are greater merits to choose from. We are more similar than different :) in foss community I suppose
Another thing is that sometimes, people don't like taglines telling how good the project is, like I searched fish and I love fish but fish is a smart and user-friendly command line shell for Linux, macOS, and the rest of the family.
Maybe its me as I could only vouch for the user friendly part of fish from my small time using it (and the time I mimicked every aspect of fish for my zsh config file). I truly loved fish but I might not be sure about its smartness and what it means by that and that might be a nitpick but I still love fish and would recommend it to some people
Maybe I can be wrong, I usually am and someone please feel free to correct me to make me understand what they mean by smart, I know that somethings scripting in fish can be more pleasant than bash and it has some nice features but just smart is really vague, I hope everybody gets it :)
I'm normally very skeptical about new languages, but this one, actually looks very very promising!
At places it looks like plain old PHP without the need for <?, in other I can see some goodies from JS with a bit of Python sprinkled as well.
It really looks like the author gave it a proper thought! Good job!
This looks interesting! The syntax seems clean and the built-in concurrency features are quite appealing. Has anyone used this in production?
Altogether Brilliantly Splendid
> Bring back the joy of shell scripting.
There was joy?
Seriously though, this actually doesn't look half bad. The problem is you can easily achieve the same thing in basically any standard scripting language (Typescript, Python, etc.) just by replacing backticks with a function call.
Actually in Typescript you can use tagged string so it could just be one extra character if you want:
Is saving that one character worth using a niche language?I agree, it's a cool idea but I actually think the lack of mantainability of shell languages are a coincidental feature not a bug, making sure that once you hit a certain complexity you're forced to switch to a full programming language.
I can see the intent of the logo but it looks like it's missing a left eye.
…and winking winking with the other eye.
Naah, it looks like >_< except just ⅔ of it.
Next objective absh?
Oh boy another meaning mapped onto ABS!
I was half-expecting this language to only have the abs function, and somehow build everything around it.
Can anyone convince the Australian Bureau of Statistics to adopt it?
Another BS? Apologies, I actually do like it.
:) it's fine. I think I was just thinking of ABS today so it was stuck in my mind.
ABS brakes ABS plastic ABS function ABS muscles ABS programming language etc.