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?

Okay so how would it be done without mv..using the POSIX rename syscall?

https://pubs.opengroup.org/onlinepubs/009695399/functions/re...

mv is basically just a shim over rename so I don't see your point.

Shell may be to glue things together but it's supposed to also be a decent language for doing file/filename related things.

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.