> I wish there was a good standard alternative to bash (sh in this case) for shell programming.
I would say Tcl!
Tcl is one of the most underrated programming language that everybody probably has installed. It has existed for as long as ksh and even long before bash. It is simple and powerful enough that first version of Redis were written in it[1].
MacPorts is written in Tcl (including its ports DSL) and I enjoyed every moment working with it.
Agreed 100% with this. TCL is a super cool language IMO. It's mature, unixy, and has minimal external dependencies. The ecosystem is stable and slow moving. I would encourage anybody to try it out!
The syntax takes some adjustment because it's not lval/rval-based, which is maybe why it's not so widely used now. But if you want a language that's more robust than shell and more minimal than Python, consider TCL for your next project.
Could you explain more re: bugs? Dylan Araps sort of specialises in well-written (ba)sh and iirc uses shellcheck meticulously. I ask not to be combative in case you're just making a casual joke - more I'd like understand how bugs might creep in to (ba)sh code - even if say, one follows shellcheck and is as competent as Dylan.
I saw that after posting. It's not a critic of Dylan's work, more a critic of how difficult it is to write good bash code.
Your comment on shellcheck and Dylan expertise just confirm it. It's like C, you could write safe C but it's very difficult.
I wish there was a language with the ubiquity of Bash but modern and safe.
»I wish there was a language with the ubiquity of Bash but modern and safe«
I agree. But reaching such a point would be hard. Not impossible, but hard.
I think the main problem would be to gain traction for an alternative. Because if one questions the status quo, then there are tons of alternative paths to go by. But which of them are viable…? It’s not easy to pick a winner in this kind of situtation. And most people, even in tech, would not want to spend hours on trying out/developing a new shell that won’t gain any significant traction.
The Bourne shell was developed in the mid 70s. There were not many other scripting languages around then, so Bourne shell became a major player. They could probably have used Lisp if they wanted to, but AFAIK Lisp was not widespread within the Unix world back then.
These days we have many other models for interpreted languages. Ruby, Python, Perl, TCL, Scheme, Clojure, etc etc.
Let’s say someone wrote a Python-inspired shell that aimed to replace sh/Bash. Now you need to gain traction in order to build up a useful and sound ecosystem that has the ability to replace all those shell scripts out there. But how would you convince the Ruby fans or Scheme fans to use that? Therein lies a big challenge.
Getting people to continue using sh is not as hard, since it at least is standard, despite its shortcomings.
It works and you can try it now. The downside is that the implementation is more like a slow prototype, but that's being addressed, and the release I made today has stats about the C++ version (blog post forthcoming).
Ah I'm with you, thanks for the explanation - you're quite right. I've done a fair bit of bash and still I fully expect parts of the syntax to escape my memory. A modern and safe shell would be oil [0], ubiquity is WIP.
Honestly, PHP is a decent scripting language. It's pretty fast with text processing and you can choose to play fast-and-loose or go in a more type-checked direction.
It's basically my least favorite language for "real" programs, but I think it could find a niche for scripting in the middle of the spectrum between (ba)sh and python.
For quite some time I've been using https://github.com/tarruda/python-ush on personal scripts and it is working very well. If you like python, I recommend giving it a try :)
One thing that irks me is the verbosity of simply renaming file extensions of all files in a directory.
On Windows: ren ∗.js ∗.mjs
On Unix: for x in ∗.js; do mv "$x" "${x%.js}.mjs"; done
Feels like shells should have one line list comprehensions without the obtruse do/done. Are there any shell enhancements like zsh or the like, that make simple list operations less verbose?
I know about that utility -- still not shell though. The fact that you need a utility to make such a simple task readable is pointing to the shell language lacking.
By your own logic, your own UNIX solution to the file renaming problem is "not shell" since it uses the mv "utility". Or do you mean rename is not POSIX? The shell language certainly is lacking for almost anything beyond its original purpose of gluing together pipelines/graphs of UNIX commands; it's a largely unintentional DSL from the time before many modern notions of language ergonomics had become established. The point is, there is an array of solutions to reduce the nuisance of having to deal with the language equivalent of a stone knife such as programs like rename or actual general-purpose scripting languages. Sure, you can cut most things with a stone knife with enough time and effort but why would you if you have a bunch of sharp, metal knives within easy reach?
My point is that mv is a compiled C program, not a shell builtin or piece of shell syntax, that you may nonetheless call in a shell script to extend the functionality of the shell. rename is another such compiled C program. To say that it's awkward to batch rename files with mv may be true, but that's a deficiency of an external C program being used beyond its original purpose. Since we're using external programs anyway, you can just use one that's actually designed explicitly for the purpose renaming files.
Mv can be replaced with the rename syscall and the lack of versatility of shell is still demonstrated. Point taken though, pre packaged selection of utilities is arbitrary.
Enough to get 20 bugs :-). I wish there was a good standard alternative to bash (sh in this case) for shell programming.
Otherwise I like the spirit, it's a good match with collapse os ;-)