#UNIX is not just an OS; it is arguably the ultimate #IDE for #programmers. Arguably the best written introductory book on UNIX programming is "The UNIX Programming Environment", Kernighan (1983). This book covers UNIX V7, but I used it with 4.2BSD.

There is another jewel of a book of a similar kind, a free one to boot, by Prof. Ballesteros (King Juan Carlos University): "Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs" (2007). Prof. Ballesteros wrote this book to teach his CS students the fundamentals of good OS design.

Although almost no one uses #Plan9 today, it is alive and kicking. It even runs on Raspberry Pi. Anyone interested in OSs and likes the philosophical underpinnings of UNIX should take a look at Plan 9.

The other must-read book is his "Notes on the Plan 9 3ed Kernel Source" (2007). It is a Lions-style commentary.

Prof. Ballesteros has many Plan 9 related publications in PDF format.

https://lsub.org/books-papers/

PS—Those with a historical bent should also read Organick's "The Multics System: An Examination of Its Structure" (1980). Multix is the mother of UNIX, and Plan 9 is the grown-up UNIX.

Books and papers

These are some publications and books I wrote. They are arranged on sections depending on the system they refer to, or put in the miscellaneous section if they do not refer to a particular system w…

Fran. J. Ballesteros
@AmenZwa agreed. part of The Unix Way, imo, was that any terminal provided a de facto IDE. you just have to learn the various CLI tools and shell patterns and common keystrokes etc. I think the more modern trend of ostensible IDEs made more sense in reaction to what MS Windows and early Mac gave a programmer out of the box. if you can already get what you need they appeal less

@synlogic4242
Of course, it is a bit unfair for us "moderns" to compare UNIX to the likes of NeXTSTEP, Windows, macOS, and such. This comparison came about, because UNIX, starting in the early 1980s, began competing in the PC market, and soon gave birth to the workstation OSs of the time: SunOS, IRIX, Ultrix, AIX, HP/UX, and so on, sporting the X Window System. But despite all those modern accoutrements, UNIX was still very much the 1960s time-sharing OS, not a personal OS. That heritage continues into the modern UNIXen, like FreeBSD, NetBSD, OpenBSD, and Darwin.

Looking upon UNIX in its period-correct context—during the late 1960s and the early 1970s when batch processing on mainframes over the teletype is the fashion of the day—what Thompson and Ritchie achieved in such a short time frame is, frankly, a superhuman achievement.

I do not recall the exact phrase, but I once read something like this in a Bell Labs publication: "UNIX was created by programmers for programmers to do programming". In other words, Thompson created UNIX to make his daily programming activities more efficient, effective, and enjoyable.

UNIX, therefore, is the world's first IDE. By "IDE", I do not refer to modern, surface-indicia of programming, such as buttons, scroll bars, and menus; I mean a unified, coherent system designed, ab initio, to serve as the ultimate software development environment, integrating all programming-related tools that a programmer would need.

In contrast, most popular operating systems (OS/360, VAX/VMS, Windows, macOS, etc.) are designed for non-techie business users.

@AmenZwa
> most popular operating systems (OS/360, VAX/VMS, Windows, macOS, etc.) are designed for non-techie business users.

Abbreviated like that, it is arguable. Expanding the wording:

> most popular operating systems (...) are designed for *applications* aimed at non-techie business users, not at programmers.

...is more bullet-proof, I think.

And it immediately implies the fundamental problem: the app makers are therefore largely not eating their own dogfood. This causes problems that have been widely explored.

@synlogic4242

@dougmerritt @AmenZwa @synlogic4242

> And it immediately implies the fundamental problem: the app makers are therefore largely not eating their own dogfood. This causes problems that have been widely explored.

I honestly feel like we have a reverse problem: the app makers don't actually understand computers or user interfaces, and the people who designed the original GUIs and knew the WHY behind everything have left or retired.

Like, I'm an affable guy. I don't like harping on #UIDesign all the time.
But our modern UI Design is absolute dogshit, if you'll forgive a little vulgarity (fairly rare for me).

It's bad enough that everything is created with 23-year-old eyes in mind, but even basic usability has suffered dramatically in the past fifteen years.

If I had a money tree and a fountain of youth, I'd go back to Uni (AGAIN 🤣) actually get my C.S. degree, and major on UI Design and be the most annoying forking UI Gadfly in all the nine realms.

@dougmerritt @AmenZwa @synlogic4242

Regarding modern UIs, I will say that I'm very happy that search has won over hierarchical menus in general*, particularly for launching applications. I love dmenu/rofi/wofi/fuzzel and even KRunner when I'm on my work machine.

When digging through work folders that are synced with the cloud and have hundreds of thousands of files (in well-organized, but still deeply nested directories), I have my own search menu system I came up using just simple old find, grep, and zstd which is actually faster and more reliable (and much, much less resource-intensive) than the search facilities provided by Gnome or KDE and their complicated daemons and databases.

* I don't mean "hamburger menus" vs. hierarchical menus, though. Those are for the birds. 😄

@rl_dane
I've been doing a bit of thinking out loud (very loudly), of late, about TUIs.

Half-jokingly, I have said, the modern user is so habituated to the text-based interaction with the computer, thanks to the almighty LLM, that it is high time for us oldies to sneak in the traditional TUIs into this generation of users's desktops.

The non-joking half is this. Modern TUIs have got so sophisticated that they now have their own unique aesthetics. Yet, they can be programmed in the same way that were done with the 1970s and 1980s TUIs. No remote calls, no async/await, etc. Some of them even have web browser integration.

Most line-of-business web apps today are used by a handful of in-house business experts only; there is absolutely no need for them to use React, Angular, and other massive web GUI frameworks. The only reason these web apps came into existence is the in-house coders wanted to get those frameworks on their resumes, so they can go work at the Big Tech.

@dougmerritt @synlogic4242

@AmenZwa @dougmerritt @synlogic4242

I'm impressed with what creatives can do with web apps, but when I have to use them for work, I cringe.

Like, a JS-heavy thing for creating music or procedural art? GRAVY

A JS-heavy thing for me to check my bank account? "Calgon, take me awaaayayyy..." 😂

I remember using TUI-and TUI-like GUIs (very, very text-heavy GUI database applications where there really wasn't enough room on a 640x480 or even 800x600 screen to waste space on much of anything but TEXT) in the 90s, and they were so efficient.

To this day, I'm still running a nearly decade-old version of an accounting application at work, because I just will NOT muck with the horrid web apps. If you see me using this old desktop program (via VNC, 'cause boyo ain't running windows on his own machine!! 😆), I'm absolutely flying through screens and menus; I have every major screen memorized and know exactly how many times to hit TAB to move from the addressee to the date field, to amount, category, memo, class, then enter, enter and on to the next thing.

If I had to use a web application for that, you'd have to put me on suicide watch. 😂

But I've actually been learning and using ed recently. For all its limitations, there s a very Zen feeling when editing text in ed, which isn't even a TUI. It is (as I'm sure all here know) an editor that would work on a terminal as dumb as the Apple I.

My only complaint with TUIs is that they lack the shared keybinds and consistency of early GUIs. Some are very vi-like or even less-like, but others are more bespoke. Going from vi to less is easy, then less to a web browser like lynx, w3m, or cha. But links/links2? Totally different keybinds, and not configurable. urgh.

Some kind of committee thing to come up with interaction standards for TUIs would be golden. Some are very intuitive, like the fedi client I use, @[email protected]. Others require a bit more learning to get comfortable with, like iamb, the Matrix client.

I often think back to the Apple Macintosh project, and Jef Raskin, who wanted to make it a text-based, and keyboard-driven system. I would have liked to see what his ideas were like, because I think it would've been a neat midpoint between the user-friendliness of modern-ish GUIs, and the sheer power of a nicely-designed interactive Unix program (TUI and not-quite-TUI).

@rl_dane I work with the kind of internal web apps you are talking about, and I'm not sure a TUI framework (the Borland one was recently open sourced and ported to Linux, right?) Is better than plain HTML. As said earlier, you dont need JS frameworks like React or Angular, those are really only appropriate for a very narrow use case, but simple HTML forms and CGIs are dead easy to understand the whole stack and pretty easy to make usable/accessible just using the built in elements with a light smattering of plain JS and CSS for interactivity and style.

There was (is) a very influential IBM TUI HIG that most TUI DOS apps comform to, as well as Windows and Motif, but which has largely fallen by the wayside as it isn't taught to new devs and isn't part of the web platform, the web just has raw tools that you can do anything with, but doesn't enforce much. I'm pretty sure you could make a webapp with the same kind of interaction as your TUI, but there isn't a sufficiently influenced force encouraging good, standard UI.

I'm not sure what those guidelines might be or how to encourage it to exist and be adopted..

@AmenZwa @dougmerritt @[email protected]

@raven667 @AmenZwa @dougmerritt

Honestly, using firefox extensions like "Vimium C" makes plain HTML a delight to use from just the keyboard.

The thing that's driving me nuts lately is that some framework-built buttons can't be searched for, and some can't be activated by vimium. They have to be found visually, and clicked on with the mouse alone.

It's so ridiculous.

@rl_dane @raven667 @dougmerritt
I once complained bitterly against the misuse of XML as a programming language (with Turing-complete extensions, of course). Then, the father of XML (Jon, who's on Mastodon), politely chimed in, saying XML was never designed to be a programming language. It most certainly was not. The original designers, like Jon, took inspiration from TeX, SGML, HTML, etc., and made something that was perfect for typed data exchange for the web era. But what do web kids do with it? They use it to store a couple of lines of configuration settings, or to create a full-fledged programming language that no human could read.

Then, there is HTML. Just like TeX and SGML before it, it is a marvellous little declarative markup. Tim designed it to share pre-print peer-reviewed papers with his colleagues. The OG arXiv, as it were. What do web kids do? They turned it into a quagmire of a GUI that culminated in Angular, React, Svelte, Elm, Ember, ..., the list that never ends, with at least three or four more JavaScript frameworks coming out every night.

Back in the 1980s, we had two-year major release, one-year minor release, and quarterly fix releases—on just about everything, from compilers to OSs to applications. That was a sustainable release engineering practice. Today's AI-infused CI/CD pipeline is inhumane (and inhuman).

I kept coaching these kids to be simple, short, sweet, and silent (as in think, don't talk; if you must talk, be sweet, short, and simple), when they design systems, both hardware and software. But the first thing they do is get on LinkedIn and either bragged about their work or ask for help. My goodness!🤦‍♂️

@AmenZwa @raven667 @dougmerritt

When weekly system updates reach into the gigabytes (compressed) download size, something is seriously fubar.

@rl_dane
I say, aren’t we well past weekly patches, what with AI-driven CI/CD pipelines and such?😆

@raven667 @dougmerritt

@AmenZwa
I don't know about *you*, chum, but *my* software knows how to patch *itself*. While it's running.

@rl_dane @raven667

At 20 W of power consumption.

@dougmerritt @AmenZwa @rl_dane @raven667

@vnikolov @dougmerritt
We can’t have the AI data centres consume all the electrical power; the real-time embedded community has to rise up and take back some of that power. We may well be consuming sub-mW individually, but we are hundreds of billions strong and we’re everywhere.

Come to think of it, if the embedded engineers were to follow the practices of the web world, each “embedded” device would now be the size of a refrigerator, and would consume 100 W or thereabouts.

@rl_dane @raven667

@AmenZwa
You can still get PDP-8s with a hefty 4 KB core memory on the used market.

@vnikolov @rl_dane @raven667

@dougmerritt
😆👍Maverick move—again!

By the way, I heard, years ago, an apocryphal story: it is said that the CSRC staff gave Ken’s old PDP-7 a fitting burial at sea (in the pond in front of the Holmdel HQ building), instead of sending it to the scrap yard. But I didn’t see that in Brian’s UNIX memoir, so it’s probably just that, a legend.

I tell ya mate, I was this close to getting that PiDP-11 replica kits, were it not for my wife’s meaningful look….

@vnikolov @rl_dane @raven667

@AmenZwa
Tell your wife she's beautiful, rub her tired feet, and order away!

I hope that PDP-7 story is apocryphal, it would be a great museum piece.

Circa 1980 a friend of mine had some random PDP-8 he used as a footrest, occasionally kicking it to break off some more of those whatchamacallit nifty DEC toggle switches.

I had no particular love (nor experience) of the PDP-8, but I was still shocked. 😱

However others I've told that story said that it was no more than the PDP-8 deserved, that it had brought it on itself. 😝

@vnikolov @rl_dane @raven667

Right!

You all have surely seen this definition:

hardware:
that part of a computer system which can be kicked.

***

Barely tangential, the following doesn't seem apocryphal to me:
at Los Alamos during the Manhattan project they had the most expensive doorstop in the world.

They measured neutron absorption of several different materials.
That included a large piece of gold, which became a doorstop, as it wasn't needed for other scientific or engineering purposes afterwards.

@dougmerritt @AmenZwa @rl_dane @raven667

@vnikolov @dougmerritt @AmenZwa @raven667

> hardware:
> that part of a computer system which can be kicked.

That definition would have helped me a lot as a kid. I asked my dad what the difference between hardware and software was, and he said, "hardware is hard, software is soft." 😂

👍🙂

From the same fortune file:

Lizzie Borden took an axe
And plunged it deep into the VAX.
Don't you envy people who
Do the things you want to do?

And to end on a positive note:

A Unix saleslady, Lenore,
Likes to work, but she likes to play more.
So she found a good way
To combine work and play
And she sells C-shells by the shore.

#Limerick

@rl_dane @dougmerritt @AmenZwa @raven667

@vnikolov @dougmerritt @AmenZwa @raven667

Haha, that last one is fantastic.

I did technically start my unix journey in csh, but I didn't really know what I was doing then.
When I started really learning shell scripting, it was with ksh, which translated easily into bash. I've now taken to writing POSIX shell more quite recently, as it can target both Linux and the BSDs without requiring an extra install on either.

But I do wonder what csh would have been like. I never did mess around with it, except as a very, very beginning unix user of SunOS in the early 90s. ;)

I used to use csh a lot, many years ago.
Like many others, I suppose, I was particularly happy with its history manipulation features.
They are all in bash now, of course, perhaps in other shells as well.
For example,
$ !?foo?:gs/bar/baz/
(I often prefer to enter a change to a previous command, rather than re-edit the command line, but that is a separate topic.)

As the documentation itself noted, the syntax of csh has "unexpected quirks"¹; for a while I put up with them.
In any case, in those days it offered significantly more than the Bourne shell _in some respects_, if I recall correctly, like expansion of variants in braces.
These features, too, have long been added to bash.

(I never used tcsh.)

_________
¹ This is a quote.
Checking it just now yielded:
csh programming considered harmful
<https://web.mit.edu/ghudson/info/csh.whynot>.
So, yes...

@rl_dane @dougmerritt @AmenZwa @raven667

@vnikolov @dougmerritt @AmenZwa @raven667

Oh wow. Those are some glorious footguns. 😂

P.S., I am ever thankful to #Djikstra for the "considered harmful" meme, even though he was desperately trying to make a point about the mathematical "provability" of algorithms that it seems no one paid heed to.

I recently discovered I was a C.S. student at UT Austin while he was teaching there, so I was likely in the same building as him at the same time, and might have even passed by him in the hall a time or two, of course having no idea who he was. 😁

@rl_dane
I never met Dijkstra. I heard he was prickly. Nevertheless, he was one of those blokes who could make a student cleverer by osmosis, just being on the same campus with him.

Good times, there were: hardware, software, wetware, the lot.

@vnikolov @dougmerritt @raven667

@vnikolov
The C Shell was indeed lightyears ahead of Bourne Shell. Korn Shell did try, but it just couldn't quite get there. But Bourne Again Shell is where it's at. It was amusing and frightening, at once, to have learned that bash had a massive security hole, for years.

@rl_dane @dougmerritt @raven667

@AmenZwa @vnikolov @dougmerritt @raven667

You should check out mksh some time. It has some very interesting improvements.

@rl_dane
Will do. Much obliged.🙏

@vnikolov @dougmerritt @raven667

@AmenZwa @vnikolov @dougmerritt @raven667

The creator is on fedi: @mirabilos

Expect very spicy takes on Unix and shell scripting (and anything else ;)... he's one of us 🤣

@rl_dane @AmenZwa @vnikolov @dougmerritt @raven667 @mirabilos
mksh is way to mainstream :)

Since IceCreamSandwich Android has used mksh as its shell.
source

@rl_dane
> mksh

Thanks, I'll check it out.

Amen:
> The C Shell was indeed lightyears ahead of Bourne Shell.

Especially interactively; even Stephen Bourne agrees, I've heard him.

Bill Joy was, as usual, very creative about both thinking up *and* adding new features. Some of the rest of us tried our hand at writing shells from scratch, but it was as an exercise that was hard enough in itself, let alone adding features. :)

For some years I used csh quite religiously. It took me a long time to see that it was less ideal for scripting. (Religion blinds one to other paths.)

Not that anything but csh and Bourne shell were available for years.

@kabel42 @AmenZwa @vnikolov @raven667 @mirabilos

@dougmerritt

I've heard similar first-hand stories about Bill, like yours, by those who were at Berkeley at the same time. I faintly recall Kurt recounting how Bill fixed and improved the buggy BBN TCP/IP stack, pretty much overnight. Am I mistaken?

I've also heard Kernighan described how Thompson wrote, or rewrote, complex pieces of software, like compilers and OS algorithms, essentially overnight.

Some guys have all the "Joy", I guess....

Were the folks at Berkeley CS, in those days, mostly cordial or corrosive?

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

@AmenZwa
Wait, you knew Kurt Schoens, really? He married my ex-girlfriend Polly.

I didn't see Bill "read the spec and implement what it said", but everyone agrees that it was fast, just not literally overnight.

Bill was superhuman, though, so I don't really see a problem with the common story.

Everyone was friendly, except a few exceptions. Eric Schmidt was standoffish and didn't seem to really socialize with anyone, although he was active. There were no remote filesystems in that era, of course, but he still hacked up some code to remote mount a disk in a different building. Over a 300 baud dialup.

At the time it somehow escaped me that he was the Bell Labs author of Lex(1), even though I used it.

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

@dougmerritt
Oh no, so sorry; I mean Kirk (McKusick). My old age....😀

I don't know Kurt Schoens.

Ah, Schmidty....

Using a VT100 over a 300 baud line made me feel good: it gave me the illusion that, when I programmed in a screen-editor, I was thinking and working at the speed of a computer.🤣

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

Myself, I reached the conclusion once that unpredictable response time hurts more than low connection speed.

I have been spared from using a bidirectional connection (to a computer) at 300 Baud.
I think the worst that has happened to me was a 1200 Baud synchronous connection for a 3270 emulator on a PC.

@AmenZwa @dougmerritt @rl_dane @kabel42 @raven667 @mirabilos

@vnikolov
I’ve only used the 3270 in the computer centre, and very briefly at that. But I guess it would have been a demanding diva, compared to the basic VT100.

@dougmerritt @rl_dane @kabel42 @raven667 @mirabilos

@AmenZwa
Y'all are casually taking this in stride, as if a remote mount at 300 baud was basically the same thing as a human terminal connection at 300 baud.

It was an impressive tour de force in an era when very few, if any, were doing such things even at vastly higher speeds.

@vnikolov @rl_dane @kabel42 @raven667 @mirabilos

@dougmerritt
I am still reading your post, over a 300 baud modem. I just got to the remote-mounting bit. Hang on.

You're absolutely right; remote mounting protocol that works over a 300 baud line, using the ideas and tools of the era, was indeed a Berkeley-worthy feat.

@vnikolov @rl_dane @kabel42 @raven667 @mirabilos

@AmenZwa @dougmerritt @vnikolov @kabel42 @raven667 @mirabilos

Oh man... I'm using @tut limited to certain baud rates using trickle, and it's completely unusable at less than anything but 9600 baud. It redraws every character onscreen several times per refresh. Infuriating. XD

Ed, of course, is a gem, even at 300 baud. XD

#TUI application developers, please test your programs at forced (low) baud rates!

cc: @sjmulder

GitHub - sjmulder/trickle: 600 baud pipe and terminal.

600 baud pipe and terminal. Contribute to sjmulder/trickle development by creating an account on GitHub.

GitHub

@rl_dane
No terminal beats ed on a DECwriter over a 300 baud line, because no terminal of the era had the patience to wait around just to beat up an end-of-life teletype in the corner of the room, desperately trying to finish rendering a line.

But, hey, who needs fancy screen editing in vi, when the entire programme is visible—and touchable—on the paper rolling off the DECwriter.

An excess of patience trumps termcap, every time.

@dougmerritt @vnikolov @kabel42 @raven667 @mirabilos @tut @sjmulder

@rl_dane @AmenZwa @dougmerritt @vnikolov @kabel42 @raven667 @tut @sjmulder yeah, jupp has optimisations for low baudrates (especially if you disable “fast status line” or the status line entirely), but nōn-ed is not fun at 300 bps (use bps, not baud… 300 baud can easily be 1200 bps or more)

@AmenZwa
I never got to know Kirk McKusick at all, for whatever reason, although long before they were married, I knew his husband Eric Allman quite well.

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

@dougmerritt @AmenZwa @kabel42 @vnikolov @raven667 @mirabilos

Wait, Eric Schmidt the ex-Google CEO that turned it evil? or another Eric Schmidt? XD

@AmenZwa @dougmerritt @kabel42 @vnikolov @raven667 @mirabilos

> I've heard similar first-hand stories about Bill, like yours, by those who were at Berkeley at the same time. I faintly recall Kurt recounting how Bill fixed and improved the buggy BBN TCP/IP stack, pretty much overnight. Am I mistaken?
>
> I've also heard Kernighan described how Thompson wrote, or rewrote, complex pieces of software, like compilers and OS algorithms, essentially overnight.

I've heard the same talk from McCusick (on YouTube, that is ;)

@dougmerritt @kabel42 @AmenZwa @vnikolov @raven667 @mirabilos

Were there a lot of differences between classic bourne sh and modern sh/POSIX sh?

That's something I was never really clear on, missing a lot of that history.

Also, I do not at all mean to be demeaning, but it doesn't surprise me that Bill Joy was the author of csh (which I didn't realize until now). According to a talk I heard from Kirk McCusick, he was amazing at churning out efficient code quickly, but it wasn't necessarily something you'd want to maintain. ;)

@rl_dane
I don't remember what POSIX sh is; if it's the same as version 6 Unix sh, then there's a big difference.

They used a trick for control flow that was cute and kept the shell itself minimal but was judged an impractical experiment:

It used goto (for expedience, not because they didn't know any better), which was an external program. This worked because the goto child process shared the open file descriptor of the shell script, which had to refer to a disk file, so when the goto did a seek(2) on that descriptor and exited, the calling shell had its offset into the file changed, causing it to e.g. goto an earlier label in the shell script.

Kind of like a fever dream.

I forgot how conditionals worked, and there weren't any other constructs like while.

It didn't support changing the prompt. If '#' was good enough for superuser, then surely '%' was good enough for everyone else.

It didn't have much of anything, in other words.

I'd have to refresh my memory about other details, though.

Bill Joy's code was impenetrable, but always very clever code. :)

In that era there was comparatively little evangelizing of code clarity and maintainability, although of course some people cared more than others.

To be fair, larger projects *had* to be clever to fit into 64 KB (128 KB separate instruction/data space option).

Elsewhere I've related the "I've got 8 bytes left" story.

@kabel42 @AmenZwa @vnikolov @raven667 @mirabilos

@dougmerritt @kabel42 @AmenZwa @vnikolov @raven667 @mirabilos

Ok, that sounds significantly different to modern Posix shell (/bin/sh). POSIX shell is honestly like a slimmed-down bash in comparison. ;)

@rl_dane
I vaguely recall POSIX sh as being similar to SVR4 sh. Am I off?

@dougmerritt @kabel42 @vnikolov @raven667 @mirabilos

@AmenZwa @dougmerritt @kabel42 @vnikolov @raven667 @mirabilos

I couldn't tell you. I am a mere babe when it comes to those old unices. 😄

@dougmerritt @kabel42 @AmenZwa @vnikolov @raven667 @mirabilos

From the McCusick talk that I watched, the BBN TCP/IP code was actually nicely designed, but just had way too much overhead for the time. Joy's code was fast, if not pretty. ;)

Having more resources allowed us to get a little more disciplined, methink, and then a lot LESS disciplined. 🤣

I'd love a link to the 8 bytes left story, if you have one. ;)

@dougmerritt @rl_dane @kabel42 @AmenZwa @vnikolov @raven667 @mirabilos
Friends tried to get me to use csh, I quickly decided that I didn't want to learn two incompatible shells, one for interactive use and one for scripting. (Yes, you can write csh scripts, but...)
@rl_dane @kabel42 @AmenZwa @vnikolov @dougmerritt @raven667 I must have told you… twice… or thrice… maybe…

@mirabilos @kabel42 @AmenZwa @vnikolov @dougmerritt @raven667

Smiles and broadly gestures to the sparkling and effervescing #ADHD.

I have the long-term memory of an elephant, and the short-term memory of a fruitfly.

Sorry.

@kabel42 @rl_dane @AmenZwa @vnikolov @dougmerritt @raven667 oy, I fought a year and a half for that

@mirabilos @kabel42 @AmenZwa @vnikolov @dougmerritt @raven667

I'm impressed you got that devilish behemoth google to do anything, although back in 2011, it almost still had the faint outline of a human soul.

@vnikolov @rl_dane @dougmerritt @AmenZwa @raven667 I used to use tcsh exclusively but I got tired of always having to install it everywhere because it's not in any system's default/base installation. And now bash has all of that command history/substitution/editing so I'm not giving up so much now by using it.

@hyc @vnikolov @dougmerritt @AmenZwa @raven667

I use bash interactively everywhere, but I'm starting to default to POSIX /bin/sh for scripts, because it's the only common denominator in terms of default installs between Linux and BSD.

Some things just aren't possible with sh, and I revert to bash. But most scripts are ok, I just miss having the "[[ ]]" version of "test," which is a lot more robust than "[ ]". Also, comparisons in "(( ))"

I still have a lot of fondness for #ksh, as it's what I learned first, and is installed by default on #OpenBSD and #NetBSD, but not #FreeBSD*, grrr. XD
(also, a friend maintains mksh, which is pretty cool)

* FreeBSD only has /bin/sh and /bin/t?csh in base. Seriously guys? What year is it? 😂

@rl_dane @hyc @vnikolov @dougmerritt @AmenZwa @raven667 Someone should rewrite bash in /bin/sh so we can run them anywhere we want.

@AnachronistJohn @raven667 @vnikolov @hyc @AmenZwa @dougmerritt

You say that, but I actually have one or two scripts that can be run in bash OR ksh, and I came really, really close to writing a posix script called "bashorksh" that would just figure out which one you had installed and exec that, so I could just put "/usr/bin/env bashorksh" in the shebang. 😄
Also, I write my .bashrc2*, .bash_functions, and .bash_aliases files in such a way that they can be executed by ksh without any problems.

* I leave the default .bashrc alone on installs, and just add a line to source .bashrc2, which I have synced between my boxes

@rl_dane @hyc @dougmerritt @raven667 @AmenZwa @vnikolov you can get oksh and mksh in packages on FreeBSD!

@silverwizard @hyc @dougmerritt @raven667 @AmenZwa @vnikolov

Oh, and I definitely do! But when I'm writing scripts that will theoretically be run by others, I can't assume they will have ksh installed, unfortunately. :/

I just defaulted to #!/bin/bash out of laziness for the longest time, but now I'm defaulting to #!/bin/sh both for compatibility and as a challenge. ;)

@rl_dane @hyc @dougmerritt @raven667 @AmenZwa @vnikolov oh sure, yeah, I always do my best to stay posix-only, I once had to do tortured logic to test if a system had tac or tail -r which sucked

@silverwizard @hyc @dougmerritt @raven667 @AmenZwa @vnikolov

Heh, I have to deal with "does it have tac/shuf/etc." and "what features does date have on this OS??" all the time. XD

Way too many of my scripts have case $(uname) in ... 😄

@rl_dane @vnikolov @dougmerritt @AmenZwa @raven667 csh considered harmful.

Interactively, if all you have are the other shells from that time (pre-ksh), it was an improvement, and brace expansion also comes from it. But don’t use it for scripting, period.

@vnikolov
I ate, worked, and slept inside a VAX-11/780 for more than a decade, but I never saw the Lizzie Borden limerick. I would have enjoyed it even more, back then, especially on those wee hours of the mornings when my bugs were mightier than I.🤣

@rl_dane @dougmerritt @raven667

@AmenZwa @vnikolov @dougmerritt @raven667

Reading up on the specs of that box on Wikipedia unlocked a memory of touring UT Austin as a kid in the 80s and standing in the hallway of the then quite small computer room as the tour guide said something like, "and this computer has sixteen megabytes of memory..." which of course impressed everyone. 😁

@rl_dane
Stallman used to travel a lot to proselytize, first emacs and then later Gnu of course.

I ran into him in Unix Review building (which just was my late friend's Jim Joyce's small office, not some huge megacorp) when he was starting to pitch Gnu, and he said authors should assume a system with one megabyte of RAM.

I complained quite bitterly. Didn't he want to be practical enough for his project to get off the ground? Only you mainframe guys have that much RAM!

Some minicomputers did, too, by then, but what I had in mind was running Unix on home systems, and I could not afford a minicomputer. Sun workstations were also out of my reach, although my friend Rich Morin had a complete Sun system (meaning extras like tape drives etc) in his basement, for his consulting business "Canta Forda Consulting" (I didn't get it at first, say it fast out loud).

@AmenZwa @vnikolov @raven667

@dougmerritt @AmenZwa @vnikolov @raven667

Yeah, emacs used to be the big and bloated behemoth IDE ^__^

@rl_dane @vnikolov @dougmerritt @AmenZwa @raven667 it was in the manuals back then

@mirabilos @vnikolov @dougmerritt @AmenZwa @raven667

Pity I never read the manuals.

Like seriously a pity. The Commodore 64 manuals were amazing.

(Because of course, that's all I had access to at the time ;)