The biggest disadvantage of the shell is that, by exchanging data using text, you lose opportunities to check for errors in the output. If you call a function in a programming language and an erroneous output happens, you get a crash or exception. In a shell, you'll get empty lines or, worse, incorrect lines, that will propagate to the rest of the script. This makes it impractical to write large scripts and debugging them gets more and more complicated. The shell works well for a few lines of script, any more than that and it becomes a frustrating experience.
It's even worse than that. Most non-trivial, and some trivial scripts and one liners rely on naive parsing (regex/cut etc) because that's the only tool in the toolbox. This resulted in some horrific problems over the years.
I take a somewhat hard line that scripts and terminals are for executing sequential commands naively only. Call it "glue". If you're writing a program, use a higher level programming language and parse things properly.
This problem of course does tend to turn up in higher level languages but at least you can pull a proper parser in off the shelf there if you need to.
Notably if I see anyone parsing CSVs with cut again I'm going to die inside. Try unpicking a problem where someone put in the name field "Smith, Bob"...
that's why the rule #1 of robust shell scripts is "set -e", exit on any error. This is not perfect, but helps with most of the errors.
set -euo pipefail, if you're OK with the Bashism.
I always tell people the best way to learn how to use linux is to read The Unix Programming Environment.
Perl superseded it for almost all of the chapters, except for the C ones. Altough for small programs, for sure it did.
Perl used to have an AWK to Perl converter because most of the language could be mapped 1:1 to Perl.
UPE would be fine under 9front save for sh (rc) and make (mk).
I liked awk and perl was even better where either more structured (I know, I know) constructs were comfy or I needed perl dbi (which was awesome, what do people use now?) but that was a while ago. Sort of nuts that awk is much faster on really big columnar (csv etc) data, though.
Today Unix philisophy it's better done at 9front than the Unix clones themselves.
>Functional + universal data structure + homoiconic = power
It everything used TSV or tabular data, yes. But is not the case. With lisp you can always be sure.
>I edit my entries in Emacs.
Emacs can do dired (ls+vidir), eshell, rsync maybe to s3 (emacs package+rclone), markdown to HTML (and more from ORG Mode) and tons more with Elisp. With ORG you can basically define your blog and with little of Elisp you could upload your blog upon finishing.
>21st Century Terminal
Eshell, or Emacs itself.
>. What if we take the idea of Unix programs as pure functions over streams of data a little further? What about higher-order functions? Or function transformations? Combinators?
Hello Elisp. On combinators, maybe that shell from Dave from CCA. MPSH? https://www.cca.org/mpsh/
Every time people praise Emacs like this, I wonder if I just don’t get it or they have an Emacs-shaped hammer and only see Emacs-shaped nails. Lots of braced nails, naturally.
Elisp is dependent on Emacs. It is useful to have a language that you can run without loading Emacs.
I'm on board with this.
Unix is my favorite OS.
I like that it's fundamental unit of work is the process, and that, as users, we have ready access to those. Processes are cheap and easy.
I can stack them together with a | character. I can shove them in the background with a & (or ^Z and bg, or whatever). Cron is simple. at(1) and batch(1) are simple.
The early machines I worked on, processes were a preallocated thing on boot. They weren't some disposable piece of work. You could do a lot with it, but it's not the same.
Even when I was working on VMS, I "never" started new processes. Not like you do in Unix. Not ad hoc, "just for a second". No, I just worked directly with what I had. I could not compose new workflows readily out of processes.
Processes give a lot of isolation and safety. If a process goes mad, it's (usually) easily killed with little impact to the overall system. Thus its cheap and forgiving to mess up with processes.
inetd was a great idea. Tie stdin/stdout to a socket. Any one and their brother Frank could write a service managed by inetd -- in anything. CGI-BIN is the same way. The http server does the routing, the process manages the rest. Can you imagine shared hosting without processes? I shudder at the thought.
Binary processes are cheap too, with shared code segments making easy forks, fast startup, low system impact. The interpreters, of course, wrecked that whole thing. And, arguably, the systems were "fast enough" to make that impact low.
But inetd, running binary processes? That is not a slow server. It can be faster (pre-forking, threads, dedicated daemons), but that combo is not necessarily slow. I think the sqlite folks basically do this with Fossil on their server.
Note, I'm not harping on "one process, one thing", that's different. Turns out when processes are cheap and nimble, then that concept kind of glitters at the bottom of the pan. But that's policy, not capability.
But the Unix system is just crazy malleable and powerful. People talk about a post-holocaust system. How they want something like CP/M cuz its simple. But, really? What a horrific system! Yes, a "unix like system" is an order of magnitude more complex than something like CP/M. But its far more than an order of magnitude more capable. It's worth the expense.
Even something weak, like Coherent on a 286. Yea, it had its limitations, but the fundamentals were there. At the end of the world, just give me a small kernel, sh, vi, cc, and ld -- I can write the rest of the userland -- poorly :).
On shells for Unix, this can be really useful to cut script regex matching in half:
The author of the article seems unaware of awk or jq or perl one-liners for handling JSON or other forms of data from UNIX command line.
The contents of the article indicate you're mistaken:
> You really can use the best tool for the job. I've got Bash scripts, awk scripts, Python scripts, some Perl scripts. What I program in at the moment depends on my mood and practical considerations.
You often have to do dances with JSON, XML, TSV... converters before parsing the actual data.
If you use something like Emacs, you just handle s-exps.