hckrnws

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?

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.

Indeed. I cannot tell you how many time I've 'wasted time' on a one-line sed script or 10 lines of awk that obviously would have been better spent on several times that number of lines of a 'modern' language, that I would have to install before I could use. Terrible...something only a boomer would do, amiright. YMMV, though.

I might do the same if there isn't anything already pre installed. On most of the RHEL machines I've used there has at least been some Python or Perl interpreter installed. Maybe that was just something the IT folks did.

I'm not really talking about making something longer just to be more clear either. I just meant all the nice libraries and Python data structures seem to allow me to do complex things in a short amount of code. Bash and Awk and all the Linux commands are great for simple things, but I haven't figured out how to handle more complex data outputs.

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.

It seems that some kind of piping is possible: https://github.com/abs-lang/abs/blob/master/examples/pipe.ab...

I'm pretty sure that's "interior" piping to ABS functions like split() and map()

As opposed to "exterior" piping to executables like grep and xargs, which may be written in any language

I believe the comment you're replying to is saying that's a design MISTAKE

And I agree -- in trying to make shell more consistent, you've actually REDUCED its power

I wrote a blog post about this issue:

Oils Is Exterior-First (Code, Text, and Structured Data) - https://www.oilshell.org/blog/2023/06/ysh-design.html

(which was aimed at people working on Oils, not general users. Hopefully a more concise/illustrative post will appear, though I also welcome anyone else like the OP who wants to argue this ! )

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-0.35$ diff -u <(seq 2 3) <(seq 1 4)
    ...
    +1
    2
    3
    +4

      cat  <(seq ) <(seq 1 4); echo hi
           ^~
    [ interactive ]:39: errexit PID 693013: Command failed with status 1

    var obj = {}
    for n in (1 ..< 10) {
      if (n % 2 === 0) {
       setvar obj[str(n)] = 6 ** 2  # no rand function now
      }  
    }
    = obj  # pretty print with =
  
    # => (Dict)  {'2': 36, '4': 36, '6': 36, '8': 36}

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

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?

"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.

> 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:

  let result = x`ls -l`;

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'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!

Found first (!) thing that I cannot justify: sleep(number) sleeps for number of MILLISECONDS rather than - more naturally - seconds. The only possible explanation I found is that this maybe accepts a int rather than a float. (In this case the function should be called sleep_ms, not unlike unix_ms)

This looks interesting! The syntax seems clean and the built-in concurrency features are quite appealing. Has anyone used this in production?

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 :)

Yes, obviously I'm making a bit of a strong point here, undiluted by necessary nuance. I don't shun otherwise good projects with a good reputation entirely from a mere sentence if I can avoid it.

But the point is, I actually enjoy scripting in bash. Half the time people rant about it, there's something wrong in the argument. Not always of course, different tools for different people and all that. But having someone's primary marketing argument be a strong implication that "finally you can get rid of shitty bash and bring the joy back" rubs me the wrong way because for me it's not shitty and I'm already experiencing joy. So what I'm getting from the tagline is that it's condescending, uninformative, and the vibe I'm getting is that it's going to mess with what already works by suggesting oversimplified workarounds, which fail when you actually need that desired complexity. So this is already negatively predisposing me when it could have been avoided.

Fish is similar, if you go to the webpage (https://fishshell.com/), the primary tagline isn't the one you mentioned (which I would have been very happy with), it's "Finally, a command line shell for the 90s". To me that's just petty, and this is despite the fact that I have tried fish before and liked it. Ironically, I then moved back to bash because in the end I decided it was still better.

This isn't Coke vs Pepsi ads. I'm sure a project serving as an alternative for another popular project can promote itself without such pettiness right as the first sentence in the website. "Discover the joy of shell scripting" would have been great; but "Bring back" is petty.

Next objective absh?

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.

Altogether Brilliantly Splendid

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.