[HN Gopher] The Heart of Unix (2018)
___________________________________________________________________
The Heart of Unix (2018)
Author : kugurerdem
Score : 51 points
Date : 2024-10-03 19:25 UTC (3 hours ago)
(HTM) web link (ericnormand.me)
(TXT) w3m dump (ericnormand.me)
| anthk wrote:
| 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/
| coliveira wrote:
| Elisp is dependent on Emacs. It is useful to have a language
| that you can run without loading Emacs.
| 9dev wrote:
| 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.
| anthk wrote:
| On shells for Unix, this can be really useful to cut script regex
| matching in half:
|
| https://www.cca.org/mpsh/docs-08.html
| mmcgaha wrote:
| I always tell people the best way to learn how to use linux is to
| read The Unix Programming Environment.
| anthk wrote:
| 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).
| gregw2 wrote:
| 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.
| taejavu wrote:
| 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.
| anthk wrote:
| 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.
| coliveira wrote:
| 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.
| theamk wrote:
| 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.
| hggigg wrote:
| 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"...
| whartung wrote:
| 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 :).
___________________________________________________________________
(page generated 2024-10-03 23:00 UTC)