When Steve Jobs was still alive, all versions of macOS came with a host of important Unix tools. Nowadays, not so much. In Catalina and beyond I found these tools suddenly missing:

* emacs – my preferred text editor.
* RCS – my preferred revision control system. Ancient, but fully capable if you’re the only person working on your code. And very easy to administer.
* ccrypt – a file/directory encryption/decryption tool that I like.
* Probably others.

I couldn’t survive without emacs and RCS. And would greatly miss ccrypt.

Fortunately, thanks to Homebrew, I still have those tools, even on my current MacBook with an M3 chipset running macOS Sonoma.

Homebrew is an open source package manager for macOS (and Linux), and it works very well indeed. My emacs text editor is fully aware of RCS and ccrypt. I also used Homebrew to get SNOBOL4, an ancient, but marvelous, computer language, unknown to most folks nowadays.

How to get Homebrew:
https://docs.brew.sh/Installation

Homebrew is free, but contributions are accepted. I contribute. After installation it’s easy to use. A few examples:

% brew help – get started

% brew formulae – list all available formulae (formulae is a brew term for package)

% brew list – lists all installed packages

% brew search <search term> – list the available packages that you can install.

% brew install <package> – install that package.

% brew uninstall <package> – remove that package.

Homebrew is great, but those who might be interested in installing homebrew and various packages on recent versions of macOS should be aware that the default macOS disk mounts preclude this in that the file system location where packages are installed (/usr/local) is read-only and "sealed" the latter being a macOS-specific extra layer of "protection" that is not easy to defeat. One must boot to recovery mode and perform some magics in the Terminal to alter the mount flags. To date, I have not been successful in doing so.

I suspect that if one were to succeed in mounting / r/w, that macOS would complain to high heaven and make a real pest of itself.

It may be possible to use an overlay mount to have a r/w /usr/local, but I have not explored this and I don't remember if overlays are supported on APFS.

Bottom line: Homebrew is no longer a practical option for most Mac users.

MacPorts <https://macports.org> appears to still be a viable alternative although a little more complicated to use. For example, by default it builds ports from source code so you have to have XCode installed, and be at least a little familiar with how to use a compiler, etc.

I value your comments architect, but your post puzzles me. I’m currently running Sonoma, the latest released macOS, AFAIK, on a MacBook with an M3 chipset.

As i mentioned in my OP, I’ve installed these Homebrew packages:
* emacs
* RCS
* ccrypt
* SNOBOL4 (a computer language)

Using the standard Homebrew install process, all installed easily and macOS didn’t “complain to high heaven”. In fact, it didn’t complain at all. And all packages work perfectly.

Please comment further!

This message has been edited. Last edited by: Pipe Smoker,

quote:

Originally posted by Pipe Smoker:
* RCS – my preferred revision control system. Ancient, but fully capable if you’re the only person working on your code. And very easy to administer.

RCS? I'm not throwing down on you Pipe Smoker but is this better than Git? Seems like Git is free, easy to use, multi platform, and an industry standard. If you would ever decide to share your code, no issues. I only ask because there have been a lot of version control repos and Git seems to be on top.

^^^^^
Possibly true. But I’ve used RCS for 30 years. It does everything I want and I like it. And, as I mentioned above, I’m the only person working on my code and it’s simple to administer. Childishly simple.

quote:

Originally posted by Pipe Smoker:
^^^^^
Possibly true. But I’ve used RCS for 30 years. It does everything I want and I like it. And, as I mentioned above, I’m the only person working on my code and it’s simple to administer. Childishly simple.

Got it. Best wishes pipe smoker.

Pipe Smoker, I have to ask… what are you writing code for? What is the software you are creating with these languages?

^^^^^
I write programs to make my life easier/better. A couple of examples:

Example 1 – My T-Mobile plan has a limited amount of unthrottled Hotspot data in each monthly period. So I wrote a program to keep track of my Hotspot data usage. It does this:
* Prompts me to enter the amount used today. I get that info from the T-Mobile app on my iPhone.
* It then produces a nicely formatted report with the following fields:
Day and date
Amount used today
Amount used in period
Average daily usage over the last 30 days
Prediction of amount that I’ll use in current period
Number of days remaining in current period
(The T-Mobile app also reports that, but often incorrectly)

Example 2 – I value the Clippings (Notes and Highlights) of my Kindle books. The Kindle has them in chronological order. A lousy organization if you read book A awhile, then book B awhile, then book A, etc. So I wrote a program that sorts my Kindle Clippings multiple ways. The most significant order is author name. The 2nd most significant is book title. 3rd most is location in book. A MUCH more useful order.

Example 3 – I hate spreadsheets, especially Apple Numbers. So I wrote special purpose relational database programs to replace all spreadsheets that I’d previously created on my MacBook.

I’ll just add that I consider writing programs to be great recreation!

quote:

Originally posted by Pipe Smoker:
I value your comments architect, but your post puzzles me. I’m currently running Sonoma, the latest released macOS, AFAIK, on a MacBook with an M3 chipset.

As i mentioned in my OP, I’ve installed these Homebrew packages:
* emacs
* RCS
* ccrypt
* SNOBOL4 (a computer language)

Using the standard Homebrew install process, all installed easily and macOS didn’t “complain to high heaven”. In fact, it didn’t complain at all. And all packages work perfectly.

Please comment further!

Well, homebrew running on my M2 Pro mini (Sonoma 14.6.1 (23G93))simply refuses to install any ports under /usr/local because the / file system is mounted read-only and "immutable," making /usr/local/bin unwriteable.

Attempting to change this simply does not work in multi-user mode.

e.g.
# ls -ldO /
drwxr-xr-x 20 root wheel sunlnk 640 Aug 4 06:31 /
# chflags nosunlnk /
chflags: /: Operation not permitted
# chflags 0 /
chflags: /: Operation not permitted

When booting to recovery, the chflags no longer complains, but on subsequently going multi-user the restriction is reinstated. Nor am I able to mount /usr/local from an alternative disk partition. macOS appears to have yet another file system "protection" tool that I have been unable to decipher. This has been the case for several of the last OS versions at least, although an older Mac on which I'm running High Sierra does not have this restriction.

Maybe if I were to deinstall/reinstall homebrew from scratch, it would know how to deal with my system. I installed homebrew at least 10 years and two systems ago. Although I can't do this until /usr/local is first made writable.

MacPorts, in contrast, installs into /usr/opt, which is writable (but the mount is flagged "hidden) so many utilities choose to not show it.

I'd be interested to know how your root fs is mounted, and details on /usr/local too.

On a side note, SNOBOL was one of the languages I learned in my first programming course circa 1968. I loved that language, and I think I still have my course book for it kicking around here somewhere. I used to use GNU Emacs for pretty much everything, but have long abandoned it for vi, although I still find my fingers trying to do emacs.stuff from time to time.

Running homebrew on 2 PowerBooks but I’d have to confirm install location. The work one I know is in /opt. A preferred install location of the support team of that large business concern. I didn’t care, as long as the PATH is good. Brew update and brew install still work just fine.

First eMacs user I’ve run across in some time. I usually vi, except VSCode for markdown docs because preview mode. Even though VsCode has vi mode, I usually just sit in terminal because I’m faster that way. VSCode could really almost be the new eMacs.

quote:

Originally posted by Pipe Smoker:

* emacs – my preferred text editor.
* RCS – my preferred revision control system. Ancient, but fully capable if you’re the only person working on your code. And very easy to administer.

I couldn’t survive without emacs and RCS.

RCS: During the years that I worked at Bell Labs, we used sccs(1) and make(1) for our various projects.

emacs: There were a bunch of editors available, each developer was free to use whichever one s/he wanted to. Most of us chose to work with vi, although emacs was there for any misguided souls who preferred it.

quote:

Originally posted by architect:
<snip>
On a side note, SNOBOL was one of the languages I learned in my first programming course circa 1968. I loved that language
<snip>

Like you, I first encountered SNOBOL4 about 1968. I was working at Control Data Corp. in Minnesota as a digital logic designer. SNOBOL4 ran on CDC mainframe computers, and I, too, loved the language. Things that are tedious in most languages are simple in SNOBOL4. I taught myself how to use it from “The Green Book”.

Several years ago I was delighted to discover that I could get SPITBOL for my Intel MacBook. SPITBOL is an enhanced version of SNOBOL4 developed by some very smart folks at Catspaw, Inc.

Unfortunately I’ve not been able to find a SPITBOL binary for my M3 MacBook. But the Homebrew SNOBOL4 package has many of the SPITBOL enhancements:
Compiled v. interpreted.
HOST() functions
-INCLUDE for easy function management
8-bit v. 6-bit characters
exponential real numbers enabling:
— trig functions
— log functions
— binary power operator: x ^ y

Many others.

OK, there seems to be three ways to go:

1) consider MacPorts sufficient and ignore homebrew completely (except for what I already have installed).

2) go to extraordinary extents to make /usr/local writable (e.g. boot to target mode and change file system flags when mounted on a different CPU).

3) configure homebrew to install in an alternate location (since MacPorts is using /opt/local, and there is considerable overlap in what they offer, it would have to be something like /opt2/local). Non-standard and something I'd have to remember over time.

I think I'm going to stick with #1.

^^^^^^^^
A clue for you, architect:

% type snobol4
snobol4 is /opt/homebrew/bin/snobol4
%

As you can see, Homebrew and MacPorts packages WON’T interfere with each other.

The program Steve Wozniak demonstrated on the Apple 1. His was in basic, so I ported it to Bash.
#!/bin/bash
for (( i=0; i<=20; i++ ))
do
for (( j=0; j<=$i; j++ ))
do
echo -n $j
done
echo
done

quote:

Originally posted by Pipe Smoker:
^^^^^^^^
A clue for you, architect:

% type snobol4
snobol4 is /opt/homebrew/bin/snobol4
%

As you can see, Homebrew and MacPorts packages WON’T interfere with each other.

Thank you. Now, exactly how do I tell an existing homebrew installation, performed before the / r/o lockdown, to install under /opt rather than /usr/local?

^^^^^
IDK, but if you use the link in my OP it will likely bring in the new Homebrew utility that will ignore/override the old one. Or perhaps even uninstall it.

First make a list of your current Homebrew packages in case you need to reinstall them in the new. A fast, easy operation.

The new one is really slick. Good luck. Let us know how it went.

quote:

Originally posted by Pipe Smoker:
^^^^^
IDK, but if you use the link in my OP it will likely bring in the new Homebrew utility that will ignore/override the old one. Or perhaps even uninstall it.

First make a list of your current Homebrew packages in case you need to reinstall them in the new. A fast, easy operation.

The new one is really slick. Good luck. Let us know how it went.

`brew list` checks for a writable install area and ABENDS before trying to list installed packages, so no dice there. Nor will `brew update` complete for the same reason, -h (help) doesn't even work, nor does `brew list`. When I look under /usr/local/Cellar, there appears to be a subdirectory for each package.

I will go ahead and try the Sonoma package, and report back.

quote:

Originally posted by architect:

quote:

Originally posted by Pipe Smoker:
^^^^^
IDK, but if you use the link in my OP it will likely bring in the new Homebrew utility that will ignore/override the old one. Or perhaps even uninstall it.

First make a list of your current Homebrew packages in case you need to reinstall them in the new. A fast, easy operation.

The new one is really slick. Good luck. Let us know how it went.

I will go ahead and try the Sonoma package, and report back.

OK, so installation of the current homebrew package works installing under /opt/homebrew. Of course, all my paths are now wrong, and I still have no way to uninstall the old stuff in /usr/local so conflicts are bound to occur even if Apple does not implement a new "architectural security update."

With reference to the latter, I fail to see the practical utility of "protecting" /usr/local from us careless and stupid sysadmins, while pushing the long established and well understood /usr/local functionality under /opt. Do they think the bad guys won't notice? ISTR that Sun tried something like this back in the SunOS->Solaris days with little effect except to frustrate experienced system administrators. Don't even get me started on X Windows (various conflicting install locations, and now there's Wayland to deal with)!

Why do the open source OS distributions seem to do the job of installing/maintaining/securing aftermarket software so much better than the commercial vendors? Just spitballin' here, but maybe they simply care more about their audience and reputations?

^^^^^
I feel your pain – every time I encounter the dim bulb “geniuses” at the Apple Store nowadays. It was different while Steve Jobs, a true genius, lived. Tim Cook is a mere bean counter.

I’ll mention again that Homebrew accepts contributions. They are worthy.