> A lot developers just choose shell(sh, bash, ...) scripts for such tasks,
> by using < to redirect input, > to redirect output and '|' to pipe outputs.
> In my experience, this is the only good parts of shell script.
If you try to use shell as a general purpose programming language, of course it sucks.
If you treat shell as a DSL for files and streams, nothing can beat it. Shell is amazing.
I'm sceptical a bunch of Rust macros can beat shell. I think you'd better off writing a few smaller programs that use STDIO and stringing them together with shell.
I had wrote some shell software (~5k loc without comment i think?) and agree.
I was using shell because the project want to maintain compatibility between different distros (including some weird customized one without `ps` and `sed`), but that's all. Shell is not a good choice for things other than scripting.
I’ve written a ridiculous number of shell scripts to automate many many things. It’s great for doing something now, and it’s great as a way to interact with a machine. It is not great in all cases. Particularly: array handling is bad, it’s slow if you start using actual Bashisms, very few younger devs seem to know it.
The shell is great cuz it’s there and it can cover about 50% of use cases for server side automation, but it’s bad for the reasons mentioned above.
The problem with shell scripting is that it's not meant to be a programming language at all. Its philosophy is that anything that can be a program should be, with a few capabilities and builtins sprinkled on top.
That is uninspiring... is totally fine to have long shell scripts, and in itself, is no easier nor harder than any other language.
Worth noting that shell is a programing environment (not language) so is highly dependent on the tools you are using or gluing together to accomplish something.
> For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language.
Shell is a bad language, but it is a language especially fitting for that purpose. File manipulation and external tool execution is much simpler and concise in it that in most other languages.
Well, shell scripts are small helper programs, where you don't have to implement all sorts of business rules and complex object interactions. I am pretty sure most developers (I definitely) would be horrified at the prospect of having to to implement in shell what we are now doing in JS. Even if that were possible.
The likes this gets is the design simplicity and uniformity (across processes), not how it looks and what it actually does.
That's probably because most people only sporadically have to write shellscripts. If you had to write it every day, I bet you wouldn't have that problem.
Having said that, I personally don't feel shellscripting is all that intuitive either.
The problem with shell scripts is the same as automation a gui.
It’s flakey and hard to maintain.
Grepping through output
No uniform handling of spaces, tabs. No data structures. Multiple dialects.
Shell scripts mainly work with files and process management. So many scripts don’t handle spaces correctly. This is not a problem of the creator, but because of the language.
Honestly, I'd sooner go the other way.
reply