It’s possible to set up Time Machine drives from the command line. This is way more convenient and becomes scriptable (there’s one GUI checkbox at the end if you encrypt, so the drive can unlock itself). Also, based on my own personal experience, the Time Machine GUI can be unresponsive so the CLI is much better.

I’ll be using a 1TB external SSD in this guide.

Here’s how you set up a drive.

Prerequisites

Some of these terminal commands require Full Disk Access. Specifically, the tmutil commands we’ll be using later on.

Grant your preferred terminal app full disk access in System Settings -> Privacy & Security -> Full Disk Access.

Identifying the Drive

Plug in your drive. Unlock it if you have to.

Run the following to get some information we’ll need.

Here is what you’ll see if the drive is currently being used for Time Machine:

$ diskutil list external

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                 Apple_APFS Container disk5         1000.0 GB  disk4s2

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk5
                                 Physical Store disk4s2
   1:                APFS Volume backup                  768.2 GB   disk5s1

Here is what you’ll see if the drive is brand new:

$ diskutil list external

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk4
   1:               Windows_NTFS Untitled                1.0 TB     disk4s1

Two identifiers matter here:

• disk4 — the whole physical disk. We’ll need this later on when running the eraseDisk command.
• disk5 — the APFS container. This is what we’ll need for the addVolume command. (A brand new drive won’t have this one yet. It’ll get created when we erase the disk in a later step.)

Warning:

eraseDisk destroys everything on whichever disk you name. Confirm you’ve got the right one before running it or you might nuke your local drive instead of your backup drive.

Confirm that you have the correct disk with this command.

$ diskutil info disk4 | grep -iE "device location|protocol|disk size"

Protocol:                  USB
Disk Size:                 1.0 TB (1000204140544 Bytes) (exactly 1953523712 512-Byte-Units)
Device Location:           External

We know this one is the external drive due to the Device Location: External line. On Apple silicon the internal drive shows Protocol: Apple Fabric and Device Location: Internal.

Erasing the Disk

We’ll need to erase the disk next. The steps vary slightly depending on whether the drive is brand new or is an existing Time Machine drive.

Erasing a Brand New Drive

New drives usually ship as ExFAT with an MBR partition scheme, so there’s no APFS container yet. We can erase and convert the disk with this command:

$ diskutil eraseDisk APFS backup GPT disk4

Started erase on disk4
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk4s2 as APFS with name backup
Mounting disk
Finished erase on disk4

This results in a drive with a GPT scheme, an EFI partition, and an APFS container with one volume in it (read more on containers vs volumes in APFS: Containers and Volumes). It does not encrypt the volume, enable ownership, or set the Time Machine role, which are all things we need. So we’ll delete this newly created volume and create a proper one later.

Run this again to figure out the identifier:

$ diskutil list external

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                 Apple_APFS Container disk5         1000.0 GB  disk4s2

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk5
                                 Physical Store disk4s2
   1:                APFS Volume backup                  806.9 KB   disk5s1

The identifier is disk5s1 in this case.

Now use that identifier to delete the volume that was created in the eraseDisk step:

$ diskutil apfs deleteVolume disk5s1

Started APFS operation
Deleting APFS Volume from its APFS Container
Unmounting disk5s1
Erasing any xART session referenced by 40D7443F-46DA-4DA5-9F61-41AEEBEAA1CF
Deleting Volume
Removing any Preboot and Recovery Directories
Finished APFS operation

That’s it for this section. Skip ahead to the “Creating a Volume” section.

Erasing a Drive Already Used for Time Machine

If the drive is already being used for Time Machine we need to remove the destination (the disk entry in the Time Machine GUI).

First, figure out the destination UUID:

$ tmutil destinationinfo

====================================================
Name          : backup
Kind          : Local
Mount Point   : /Volumes/backup
ID            : E10FD749-891E-4051-9135-3457E80F90E7

Then remove the old destination. We’re using sudo so it’ll prompt you for your machine’s password.

$ sudo tmutil removedestination E10FD749-891E-4051-9135-3457E80F90E7

Verify it’s gone:

$ tmutil destinationinfo

tmutil: No destinations configured.

You can double check that this worked by checking in System Settings -> General -> Time Machine. There should be no backup drive listed. If it’s still there, you can manually remove it in the GUI.

Now delete the old volume. The container stays, so there’s no need to repartition the whole disk:

$ diskutil apfs deleteVolume disk5s1

Started APFS operation
Deleting APFS Volume from its APFS Container
Unmounting disk5s1
Erasing any xART session referenced by 016C2F32-854B-4B94-8B87-DEA1774902CB
Deleting Volume
Removing any Preboot and Recovery Directories
Finished APFS operation

Warning:

If you get an error like:

The volume on disk4 couldn't be unmounted because it is in use by process 48552 (mdwrite)
Error: -69877: Couldn't open device

That’s Spotlight. Removing the Time Machine destination makes macOS stop treating the drive as a backup target, so Spotlight starts indexing it like any other volume and holds it open.

Turn indexing off for that volume and try again:

sudo mdutil -i off /Volumes/backup

Creating a Volume

Now that the external drive has been erased, we need to create an APFS volume on the drive. Decide if you want your backups to be unencrypted or encrypted and follow the corresponding steps.

Note that this only worked for me with the -role T flag in the commands. Do not leave it out! If you skip this option, macOS deletes the volume you just created and builds its own in its place when you register the drive in a later step. It has to do with APFS volume roles. The T role is for Time Machine backup stores. You can read more about these roles here: How do APFS volume roles work?.

Creating a Volume Without Encryption

Run the following command to create a volume without encryption:

$ diskutil apfs addVolume disk5 APFS backup -role T

Will export new APFS Volume "backup" from APFS Container Reference disk5
Started APFS operation on disk5
Preparing to add APFS Volume to APFS Container disk5
Creating APFS Volume
Created new APFS Volume disk5s2
Mounting APFS Volume
Setting volume permissions
Disk from APFS operation: disk5s2
Finished APFS operation on disk5

Creating a Volume With Encryption

Run the following command. It’ll prompt you for a password for your drive.

$ diskutil apfs addVolume disk5 APFS backup -passprompt -role T

Passphrase:
Repeat passphrase:
Will export new encrypted APFS Volume "backup" from APFS Container Reference disk5
Started APFS operation on disk5
Preparing to add APFS Volume to APFS Container disk5
Creating APFS Volume
Created new APFS Volume disk5s2
Mounting APFS Volume
Setting volume permissions
Disk from APFS operation: disk5s2
Finished APFS operation on disk5

Run this to confirm everything went well.

$ diskutil apfs list disk5 | grep -E "Volume disk|Role|Name:|FileVault"

    +-> Volume disk5s2 E3EA1B15-B920-4313-AB30-01E4AF10A27D
        APFS Volume Disk (Role):   disk5s2 (Backup)
        Name:                      backup (Case-insensitive)
        FileVault:                 Yes (Unlocked)

Under disk5s2 you’ll see FileVault: Yes (Unlocked) if it’s an encrypted volume. You’ll see FileVault: No if it’s an unencrypted volume.

Two things to note here:

• The volume identifier won’t always be disk5s2, APFS reuses freed slots so yours may be something like disk5s1 or disk5s3.
• Write down the volume UUID, we’ll need it later on to verify everything works.

Enabling Ownership

Time Machine refuses any destination that doesn’t enforce file ownership. It can’t preserve the UID or GID of what it backs up without file ownership. Volumes created from the command line have it turned off by default. Run the following to enable ownership, replacing the path with your own external drive’s path:

$ sudo diskutil enableOwnership /Volumes/backup

File system user/group ownership enabled

Run the following to double check that it worked. Owners should be Enabled:

$ diskutil info /Volumes/backup | grep -i owners

   Owners:                    Enabled

Registering the Drive in Time Machine

“Registering” means telling Time Machine to use this volume as a backup destination. It’s what the GUI’s “Add Backup Disk” button does. The button and the command we’re going to run both write to /Library/Preferences/com.apple.TimeMachine.plist.

Run the following to register your drive:

$ sudo tmutil setdestination -a /Volumes/backup

No output means it worked. -a appends to your destination list rather than replacing it.

If you run into this error, try waiting a bit and then try again:

/Volumes/backup: The operation couldn't be completed. Operation not supported (error 45)
The backup destination could not be added.

Then run these commands to double check everything went well:

$ tmutil destinationinfo

====================================================
Name          : backup
Kind          : Local
Mount Point   : /Volumes/backup
ID            : F746C44B-AB49-4D1A-803C-C55087343DC5

The output containing Mount Point confirms that a destination exists and its volume is reachable.

Confirm it points at your volume and not a replacement:

$ defaults read /Library/Preferences/com.apple.TimeMachine.plist Destinations | grep -A2 DestinationUUIDs

        DestinationUUIDs =         (
            "E3EA1B15-B920-4313-AB30-01E4AF10A27D"
        );

That UUID should match the one from diskutil apfs list earlier. If it doesn’t, macOS replaced your volume with one of its own, which is what happens when the -role T flag gets left out.

Note:

ID and DestinationUUIDs are different identifiers. One names the destination record and the other one names the volume it points at.

Adding Exclusions

We can add paths we want to exclude from backups through the command line too.

There are three kinds of exclusions: fixed-path exclusions, sticky exclusions, and volume exclusions. But for our purposes we only care about fixed-path and sticky exclusions.

• Fixed-path exclusions are tied to a path regardless of what is there. Use these exclusions for anything that gets deleted and recreated, like build caches.
• Sticky exclusions are the default. They’re tied to the item itself. They follows the file if you move it and copies inherit it. Deleting and recreating a directory loses its stickiness.

Here’s an example of adding a fixed-path exclusion:

$ sudo tmutil addexclusion -p ~/Library/Developer/Xcode/DerivedData

Here’s an example of adding a sticky exclusion (same command without the -p this time):

$ sudo tmutil addexclusion ~/some-directory

Check any path to make sure it was added to the exclusions. You should see [Excluded] next to the path (If you see [UNKNOWN] that means no file or directory is there, not that the exclusion didn’t register):

$ tmutil isexcluded ~/some-directory
[Excluded]  /Users/nelson/some-directory

To list fixed-path exclusions we need to read them out of the preferences plist:

$ defaults read /Library/Preferences/com.apple.TimeMachine.plist SkipPaths
(
    "/Users/nelson/Library/Developer/Xcode/DerivedData"
)

Sticky exclusions don’t appear in the preferences and are stored as an extended attribute on the item:

$ xattr -l ~/some-directory

com.apple.metadata:com_apple_backup_excludeItem: bplist00_com.apple.backupd

Removing them is similar to adding. We use removeexclusion instead. The -p flag is still necessary for removing fixed-path exclusions but not for sticky exclusions.

Here’s an example of how to remove a fixed-path exclusion:

$ sudo tmutil removeexclusion -p ~/Library/Developer/Xcode/DerivedData

And here’s an example of how to remove a sticky exclusion:

$ sudo tmutil removeexclusion ~/some-directory

Verifying That Everything Worked

Try manually starting a backup through the command line:

$ tmutil startbackup --auto --block

The command above may look like it’s stuck if your backup takes a while. You can run this in a separate terminal tab/window to monitor its progress:

$ tmutil status

Backup session status:
{
    ClientID = "com.apple.backupd";
    Percent = "0.5771912029826294";
    Running = 1;
}

If you get an error like:

tmutil: Backup already in progress.
POSIXError(_nsError: Error Domain=NSPOSIXErrorDomain Code=3 "No such process")

That just means macOS started a backup automatically.

Once it’s done you can verify with:

$ tmutil latestbackup

/Volumes/.timemachine/E3EA1B15-B920-4313-AB30-01E4AF10A27D/2026-08-01-005134.backup/2026-08-01-005134.backup

The path in the output confirms that a real backup exists. You can also check the result code:

$ defaults read /Library/Preferences/com.apple.TimeMachine.plist Destinations | grep -E "RESULT|SnapshotDates" -A2

        RESULT = 0;
        ReferenceLocalSnapshotDate = "2026-08-01 08:24:45 +0000";
        SMBConversionState = 0;
        SnapshotDates =         (
            "2026-08-01 07:51:34 +0000"
        );

RESULT = 0 means the backup was successful. Anything else means the last backup failed.

Storing an Encrypted Drive’s Passphrase in Apple Keychain

This only applies to encrypted drives.

From what I can tell, there’s no way to store the Time Machine drive’s passphrase in Apple Keychain using the command line. If you prefer your drive to unlock automatically when it’s plugged into your machine, you’ll need to do the following.

Eject the drive (change the path name to your drive’s):

$ diskutil eject /Volumes/backup

Plug it back in. When the password dialog appears, type the passphrase and check “Remember this password.” That’ll save the passphrase in your local keychain so that macOS can unlock the drive automatically next time you plug it in. No need to type in the passphrase every time.

Confirm it worked by ejecting and replugging once more. If you aren’t prompted to type in your passphrase, that means it worked. You can double check via the command line too:

$ tmutil destinationinfo

If Mount Point is present, that means the drive unlocked and mounted.

Cleaning Up Older Time Machine Drives From Apple Keychain

If you go through this process a few times there’s a good chance you’ll have several Keychain entries for old Time Machine drives. Deleting a volume doesn’t remove its Keychain entry, you’ll have to do this manually.

Normally, these Keychain entries point at volumes. But since those volumes were deleted, the entries are pointing at volumes that no longer exist. We can run the following to list all relevant Keychain entries:

$ security dump-keychain ~/Library/Keychains/login.keychain-db | awk '
/0x00000007 <blob>=/{l=$0; sub(/.*<blob>="/,"",l); sub(/"$/,"",l); lbl=l}
/"acct"<blob>=/{v=$0; sub(/.*<blob>="/,"",v); sub(/"$/,"",v); a=v}
/"svce"<blob>=/{v=$0; sub(/.*<blob>="/,"",v); sub(/"$/,"",v); if(v==a && v ~ /^[0-9A-Fa-f]{8}-/) print lbl"  "v}'

backup  016C2F32-854B-4B94-8B87-DEA1774902CB
backup  E3EA1B15-B920-4313-AB30-01E4AF10A27D

There’s two backup entries. To find the one that actually points to a volume, run:

$ diskutil apfs list | grep -E "^\s+\+->"

    +-> Volume disk5s2 E3EA1B15-B920-4313-AB30-01E4AF10A27D

So UUID E3EA1B15-B920-4313-AB30-01E4AF10A27D points to a volume. Which means UUID 016C2F32-854B-4B94-8B87-DEA1774902CB is safe to delete. We can delete it like so:

$ security delete-generic-password -s "016C2F32-854B-4B94-8B87-DEA1774902CB"

keychain: "/Users/nelson/Library/Keychains/login.keychain-db"
version: 512
class: "genp"
attributes:
    0x00000007 <blob>="backup"
    0x00000008 <blob>=<NULL>
    "acct"<blob>="016C2F32-854B-4B94-8B87-DEA1774902CB"
    "cdat"<timedate>=0x32303236303733313034303530325A00  "20260731040502Z\000"
    "crtr"<uint32>=<NULL>
    "cusi"<sint32>=<NULL>
    "desc"<blob>="Encrypted Volume Password"
    "gena"<blob>=<NULL>
    "icmt"<blob>=<NULL>
    "invi"<sint32>=<NULL>
    "mdat"<timedate>=0x32303236303733313034303530325A00  "20260731040502Z\000"
    "nega"<sint32>=<NULL>
    "prot"<blob>=<NULL>
    "scrp"<sint32>=<NULL>
    "svce"<blob>="016C2F32-854B-4B94-8B87-DEA1774902CB"
    "type"<uint32>=<NULL>
password has been deleted.

We can then double check that we only have the necessary Keychain entries left:

$ security dump-keychain ~/Library/Keychains/login.keychain-db | awk '
/0x00000007 <blob>=/{l=$0; sub(/.*<blob>="/,"",l); sub(/"$/,"",l); lbl=l}
/"acct"<blob>=/{v=$0; sub(/.*<blob>="/,"",v); sub(/"$/,"",v); a=v}
/"svce"<blob>=/{v=$0; sub(/.*<blob>="/,"",v); sub(/"$/,"",v); if(v==a && v ~ /^[0-9A-Fa-f]{8}-/) print lbl"  "v}'

backup  E3EA1B15-B920-4313-AB30-01E4AF10A27D

However, this is just for the sake of being tidy. I don’t think having these kinds of entries in Keychain affects macOS negatively in a significant way.

References

• https://support.apple.com/guide/mac-help/back-up-your-mac-with-time-machine-mh35860/mac
• https://keith.github.io/xcode-man-pages/diskutil.8.html
• https://keith.github.io/xcode-man-pages/tmutil.8.html
• https://eclecticlight.co/2024/11/21/how-do-apfs-volume-roles-work/
• https://eclecticlight.co/2024/04/02/apfs-containers-and-volumes/
• https://eclecticlight.co/2021/10/12/juggling-with-hfs-and-apfs-partitions-and-volumes-a-primer/

A snapshot doesn’t store data. It just prevents blocks from being freed. Every file that is deleted since that snapshot was taken has its blocks pinned by it. In my case, my backups had been failing since March (it’s July) so the old snapshot was never released. This old snapshot ballooned up to 226GiB.

I thought anything related to failed Time Machine backups would only take up space on the external SSD that I use for backups, but that is not the case. While macOS did warn me that my backups were failing due to my external drive being full, it never said anything about the same failure taking up 226GiB on my local drive.

The other misleading part is that deleting files wasn’t actually freeing up space!

Before I cleared the old snapshot, this is what my storage looked like. There were 974GiB used. At this time, I didn’t know that 226GiB were being taken up by an old snapshot.

$ df -h /System/Volumes/Data
Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s5   1.8Ti   974Gi   861Gi    54%    1.6M  9.0G    0%   /System/Volumes/Data

I ran this to see local snapshots:

$ tmutil listlocalsnapshots /
com.apple.TimeMachine.2026-03-15-121124.local
com.apple.TimeMachine.2026-07-30-071923.local

One of the snapshots was from today at the time of writing (2026-07-30), which is normal. The other snapshot was from 2026-03-15 (over 4 months old!), which is not normal.

More details with diskutil. Note the Purgeable: Yes lines. This means macOS would reclaim that space under disk pressure, but since I had 861GiB available that never happened.

$ diskutil apfs listSnapshots disk3s5
Snapshots for disk3s5 (2 found)
|
+-- 65156CB2-C515-478B-BAB4-333F3B069097
|   Name:        com.apple.TimeMachine.2026-03-15-121124.local
|   XID:         7888254
|   Purgeable:   Yes
|
+-- 196FCBAF-037D-45CE-BB27-1F68E5627340
    Name:        com.apple.TimeMachine.2026-07-30-071923.local
    XID:         9579327
    Purgeable:   Yes
    NOTE:        This snapshot limits the minimum size of APFS Container disk3

According to these docs, Apple says:

These files are stored for up to 24 hours or until space is needed on the disk.

And in these other docs, Apple says:

Time Machine saves one snapshot of your startup disk approximately every hour, and keeps it for 24 hours. It keeps an additional snapshot of your last successful Time Machine backup until space is needed.

Normally these snapshots expire in 24 hours. The last successful backup snapshot doesn’t expire until space pressure forces it out. So the old snapshot on my machine was expected. But since backups were failing for months the older snapshot was taking up space and saving every file I deleted since then. It was waiting for a successful backup that had not taken place since.

I deleted the local one that was old. This doesn’t affect the external backup drive and I’m only giving up the ability to restore from that point in time without my external drive plugged in.

$ sudo tmutil deletelocalsnapshots 2026-03-15-121124
Deleted local snapshot '2026-03-15-121124'

Then I checked SSD storage again to see the difference under “Used”.

$ df -h /System/Volumes/Data
Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s5   1.8Ti   748Gi   1.1Ti    41%    1.6M   11G    0%   /System/Volumes/Data

“Used” went from 974GiB to 748GiB. So 226GiB was cleared up. Crazy.

Try checking your local drive for snapshots that are older than your typical backup schedule (e.g. if you back up weekly, look for snapshots older than a week). Hourly snapshots expire after 24 hours and it’s normal to have several of these. The retained one is from your last successful backup. This is the one that stays around until space is needed. It’s only as old as your last successful backup.

For example, here’s what my snapshots look like now after everything has been fixed:

$ tmutil listlocalsnapshots /
Snapshots for disk /:
com.apple.TimeMachine.2026-07-30-071923.local
com.apple.TimeMachine.2026-07-30-084235.local
com.apple.TimeMachine.2026-07-30-185721.local
com.apple.TimeMachine.2026-07-30-202600.local

References

• https://support.apple.com/en-us/102154
• https://support.apple.com/guide/mac-help/about-time-machine-local-snapshots-mh35933/mac
• https://eclecticlight.co/2026/01/31/explainer-snapshots-2/

I’ll be using hugo as an example. Let’s say I wanted to install v0.145.0 because v0.146.0 introduced breaking changes that broke my theme.

tl;dr:

To install hugo v0.145.0:

• Create a local tap with brew tap-new $USER/local
• Tap homebrew/core which is a 1.3GB clone at the time of writing
• Extract the formula with brew extract
• Patch the hugo formula. This isn’t needed for every formula.
• Install as usual

Note that this process will point your hugo command to the older version, but you can switch between versions with brew link.

Create a local tap

Run brew tap-new $USER/local

$ brew tap-new $USER/local

Initialized empty Git repository in /opt/homebrew/Library/Taps/nelson/homebrew-local/.git/
[main (root-commit) 6af371f] Create nelson/local tap
 3 files changed, 111 insertions(+)
 create mode 100644 .github/workflows/publish.yml
 create mode 100644 .github/workflows/tests.yml
 create mode 100644 README.md
==> Created nelson/local
/opt/homebrew/Library/Taps/nelson/homebrew-local

When a pull request making changes to a formula (or formulae) becomes green
(all checks passed), then you can publish the built bottles.
To do so, label your PR as `pr-pull` and the workflow will be triggered.

It will enable developer mode. This is normal and safe.

Tap homebrew/core

Next, run brew tap --force homebrew/core. At the time of writing, it’s a 1.3GB download. This is necessary to get this working because Homebrew no longer keeps homebrew-core cloned locally. The brew extract command needs the full git history to search for older versions.

$ brew tap --force homebrew/core

✔︎ JSON API formula.jws.json                                                                                                                                    Downloaded   32.0MB/ 32.0MB
✔︎ JSON API cask.jws.json                                                                                                                                       Downloaded   15.4MB/ 15.4MB
==> Tapping homebrew/core
Cloning into '/opt/homebrew/Library/Taps/homebrew/homebrew-core'...
remote: Enumerating objects: 3385552, done.
remote: Counting objects: 100% (544/544), done.
remote: Compressing objects: 100% (119/119), done.
remote: Total 3385552 (delta 497), reused 427 (delta 425), pack-reused 3385008 (from 4)
Receiving objects: 100% (3385552/3385552), 1.08 GiB | 48.36 MiB/s, done.
Resolving deltas: 100% (2612327/2612327), done.
Tapped 5 commands and 8313 formulae (8,851 files, 1.3GB).

Extract the desired version

Now we can use brew extract. This command will find a commit where the formula was at the version we want and copy that locally as <package>@<version>.rb.

In this case we want Hugo v0.145.0, so we run brew extract --version=0.145.0 hugo $USER/local:

$ brew extract --version=0.145.0 hugo $USER/local

==> Searching repository history
==> Writing formula for hugo at 0.145.0 from revision a110fdb to:
/opt/homebrew/Library/Taps/nelson/homebrew-local/Formula/hugo@0.145.0.rb

Patch the formula

This isn’t needed for every formula and is something I ran into specifically with Hugo. Without this patch, you’ll run into errors.

After running brew extract, edit the file: /opt/homebrew/Library/Taps/$USER/homebrew-local/Formula/hugo@0.145.0.rb.

Change this line:

system "go", "build", *std_go_args(ldflags:, tags:)

To this:

system "go", "build", *std_go_args(output: bin/"hugo", ldflags:, tags:)

The reason we need to patch this file is because it prevents the error:

command not found: /opt/homebrew/Cellar/hugo@0.145.0/0.145.0/bin/hugo

It’s a mismatch between the path Homebrew expects (bin/hugo) vs the path that is created when using brew extract on Hugo (bin/hugo@0.145.0).

Install the older version

Now that Hugo is extracted and patched, we can install with brew install hugo@0.145.0:

$ brew install hugo@0.145.0

✔︎ JSON API cask.jws.json
✔︎ JSON API formula.jws.json
==> Fetching downloads for: hugo@0.145.0
✔︎ Formula hugo@0.145.0 (0.145.0)
==> Installing hugo@0.145.0 from nelson/local
==> go build -o=/opt/homebrew/Cellar/hugo@0.145.0/0.145.0/bin/hugo -tags=extended withdeploy -ldflags=-s -w -X github.com/gohugoio/hugo/common/hugo.commitHash=nelson -X github.com/gohugoio/hugo/common/
==> /opt/homebrew/Cellar/hugo@0.145.0/0.145.0/bin/hugo gen man --dir /opt/homebrew/Cellar/hugo@0.145.0/0.145.0/share/man/man1
Warning: These files were overwritten during the `brew link` step:
/opt/homebrew/etc/bash_completion.d/hugo
.
.
.
/opt/homebrew/share/zsh/site-functions/_hugo

They have been backed up to: /Users/nelson/Library/Caches/Homebrew/Backup
==> Summary
🍺  /opt/homebrew/Cellar/hugo@0.145.0/0.145.0: 53 files, 73MB, built in 8 seconds
==> Running `brew cleanup hugo@0.145.0`...
Disable this behaviour by setting `HOMEBREW_NO_INSTALL_CLEANUP=1`.
Hide these hints with `HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
==> Caveats
zsh completions have been installed to:
  /opt/homebrew/share/zsh/site-functions

Hugo v0.145.0 is now installed. There’s a warning with long output in the previous example due to the normal Hugo package being already installed but that is expected. Homebrew is now pointing the hugo binary to v0.145.0 instead of the latest version (v0.160.1 at the time of writing). We can verify with hugo version:

$ hugo version

hugo v0.145.0+extended+withdeploy darwin/arm64 BuildDate=2025-02-26T15:41:25Z VendorInfo=brew

We can also see that Hugo v0.145.0 is installed along with the latest version with brew list | grep hugo:

$ brew list | grep hugo

hugo
hugo@0.145.0

Switching Between Versions with brew link

Currently the hugo command is pointing to v0.145.0. To have it point back to the regular version, run brew unlink hugo && brew link --overwrite hugo:

$ brew unlink hugo && brew link --overwrite hugo

Unlinking /opt/homebrew/Cellar/hugo/0.160.1... 2 symlinks removed.
Linking /opt/homebrew/Cellar/hugo/0.160.1... 49 symlinks created.

And if we want hugo to point back to the old version, run brew unlink hugo@0.145.0 && brew link --overwrite hugo@0.145.0

$ brew unlink hugo@0.145.0 && brew link --overwrite hugo@0.145.0

Unlinking /opt/homebrew/Cellar/hugo@0.145.0/0.145.0... 1 symlinks removed.
Linking /opt/homebrew/Cellar/hugo@0.145.0/0.145.0... 48 symlinks created.

At first I expected brew link --overwrite hugo to work right off the bat, but running both brew unlink and brew link --overwrite is necessary to switch between versions properly. This is because Homebrew tracks linked formulas and actual symlinks on disk separately. To help Homebrew track things properly we need to run both brew unlink to clean the records, then brew link --overwrite to write the new symlinks.

There’s no need to use brew pin to prevent the older version of Hugo from updating. Since this is a local copy, there is no remote repository that would be updated that would in turn update our local version. You can even try running brew update to see the warning message:

$ brew update

==> Updating Homebrew...
Warning: No remote 'origin' in /opt/homebrew/Library/Taps/nelson/homebrew-local, skipping update!
Already up-to-date.

Removing the Older Version

If you no longer need Hugo v0.145.0 you can run brew uninstall hugo@0.145.0:

$ brew uninstall hugo@0.145.0

Uninstalling /opt/homebrew/Cellar/hugo@0.145.0/0.145.0... (53 files, 73MB)

If you don’t have any other packages you extracted with brew extract, you can also remove your local tap with brew untap $USER/local

$ brew untap $USER/local

Untapping nelson/local...
Untapped 1 formula (34 files, 36.7KB).

Finally, if you don’t plan on using brew extract again in the future, you can remove the local clone of homebrew-core with brew untap homebrew/core. This will clean up the 1.3GB of files that was downloaded:

$ brew untap homebrew/core

Untapping homebrew/core...
Untapped 5 commands and 8313 formulae (8,975 files, 1.3GB).

Then re-link hugo to the latest version with brew unlink hugo && brew link hugo:

$ brew unlink hugo && brew link hugo

Unlinking /opt/homebrew/Cellar/hugo/0.160.1... 2 symlinks removed.
Linking /opt/homebrew/Cellar/hugo/0.160.1... 49 symlinks created.

References

• https://docs.brew.sh/Manpage
• https://github.com/orgs/Homebrew/discussions/2941
• https://emmer.dev/blog/installing-old-homebrew-formula-versions/

I tried this on macOS but it should work on Linux too.

For example, when I start up a new terminal window/tab I see the following message:

After I create the .hushlogin file in my home directory, the login message goes away. First I created the file:

touch ~/.hushlogin

Then I opened a new terminal window to verify that the message no longer shows up:

References

• https://stackoverflow.com/questions/15769615/remove-last-login-message-for-new-tabs-in-terminal
• https://www.cyberciti.biz/howto/turn-off-the-login-banner-in-linux-unix-with-hushlogin-file/

To remove shadows from screenshots copy and paste this into the command line:

defaults write com.apple.screencapture "disable-shadow" -bool "true"

To reset this setting and have shadows in your screenshots again run this:

defaults delete com.apple.screencapture "disable-shadow"

Alternatively, you can press command + shift + 4 and then press space. Then hold option before you click on a window to take a screenshot. This removes the drop shadow.

References

• https://www.reddit.com/r/MacOS/comments/q7h3xl/any_way_to_take_a_screenshot_on_mac_without_the/
• https://www.idownloadblog.com/2014/08/03/how-to-remove-the-shadow-window-screenshots-on-mac-os-x/

There were several other sites covering this but they didn’t get right to the point and/or they were ad-ridden, so I decided to write a straightforward post about this.

Here’s what my brew leaves output looks like at the time of this writing:

$ brew leaves

automake
bat
black
coreutils
ffmpeg
go
htop
hugo
jq
libksba
libpq
libtool
libyaml
node
openssl@1.1
pkg-config
postgresql@14
python-typing-extensions
tldr
tree
yt-dlp
zlib

In my case, I know I don’t need the libpq package anymore. So I can remove this package and then run brew leaves again to confirm it’s gone.

$ brew remove libpq

Uninstalling /opt/homebrew/Cellar/libpq/16.1_1... (2,380 files, 29.9MB)

$ brew leaves

automake
bat
black
coreutils
ffmpeg
go
htop
hugo
jq
libksba
libtool
libyaml
node
openssl@1.1
pkg-config
postgresql@14
python-typing-extensions
tldr
tree
yt-dlp
zlib

And now libpq is gone! Try out brew leaves yourself. You may be surprised at the amount of things installed that you may not actually need.

References

• https://docs.brew.sh/Manpage#leaves---installed-on-request---installed-as-dependency

find /path/to/starting/directory/ -type d -name "directory_to_delete" -exec rm -rf {} \;

For example, if we wanted to delete all node_modules directories within the path /projects/javascript/, we would run:

find /projects/javascript/ -type d -name "node_modules" -exec rm -rf {} \;

Note:

Sometimes the output says:

find: ./node_modules: No such file or directory

But the command should still work.

If you look closely, we’re really just executing a command against all node_modules directories in the /projects/javascript/ directory (rm -rf). This command can be modified to execute other commands against all node_modules directories, but that is out of the scope of this post :)

Warning: This method is outdated!:

The approach outlined in this post still works in some cases, but as Homebrew has changed, this method has become unreliable. You may run into errors like:

Error: Couldn't find manifest matching bottle checksum.

Error: An exception occurred within a child process:
  NoMethodError: undefined method 'user' for nil

A cleaner approach is brew extract, which copies the historical formula into a local tap so Homebrew has the context it needs. See my newer post instead: How to Install a Specific Version of a Homebrew Package with brew extract.

It’s possible to install older versions of Homebrew packages by saving an older version of the corresponding Ruby file locally and running brew install <package>.rb. I’ll use the terraform package as an example.

tl;dr:

If I wanted to downgrade to Terraform 1.3.6, I would need to:

• Find the Ruby file for that specific version of Terraform on the Homebrew GitHub repo
• Download the Ruby file
• Uninstall the current version of terraform by running brew remove terraform
• Install the older version defined in the Ruby file by running HOMEBREW_DEVELOPER=true brew install --formulae terraform.rb

Let’s say we have terraform version 1.4.5 but we need terraform version 1.3.6. We can start by browsing to https://github.com/Homebrew/homebrew-core/tree/master/Formula and try to find the formula for terraform under the t directory.

Note:

Terraform has since been removed from homebrew-core after its license change, so the blob/master URL no longer exists. I’ll be using a Terraform link pinned to a specific commit hash. For any package that is still in homebrew-core, the URL pattern previously described still applies: https://github.com/Homebrew/homebrew-core/blob/master/Formula/<directory-containing-package>/<package-name>.rb

Since there are a lot of files here, it’s easier to just modify the URL path in the browser. Modify the path based on the directory the command is in: Take the name of the package and append it at the end of the url, adding /<directory-containing-package>/<package-name>.rb to the URL. The .rb is important because all Homebrew packages are defined in Ruby (files with the .rb extension).

In this case, we’ll append /t/terraform.rb to the URL like so: https://github.com/Homebrew/homebrew-core/blob/6785b6baa9a6ce18c8230de9e9f0f847547dda9a/Formula/t/terraform.rb

That URL will then take us to the Ruby file where the terraform Homebrew package is defined.

Next, click the “History” link on the upper right above the code, or just click on this link https://github.com/Homebrew/homebrew-core/commits/master/Formula/t/terraform.rb. In the next page, scroll down until you see the “terraform: update 1.3.6 bottle” link. Note that you may need to click on “Browse History” at the bottom of this page before continuing your search.

Click on the terraform: update 1.3.6 bottle link to see this page:

On the right side above the code block, click on the three dots, then click on “View file”.

This will take you to the package formula for this specific version of terraform.

On the upper right side of the code block, click on “Raw”. This gives us the exact code we need to install Terraform 1.3.6. Save the code locally to a file called terraform.rb. You can manually copy and paste or use curl:

curl https://raw.githubusercontent.com/Homebrew/homebrew-core/169f333f93fe0703b542cdf75b1decd4cb78f68d/Formula/terraform.rb > terraform.rb

Then, remove the existing package:

$ brew remove terraform

Uninstalling /usr/local/Cellar/terraform/1.4.5... (6 files, 69MB)

Then run brew install but specify the file you saved locally to install the older version. Note that as of Homebrew version 4.6.4 you can no longer install formulae directly from a file. You can get around this by specifying the environment variable HOMEBREW_DEVELOPER.

So to install Terraform from the file we just downloaded, run HOMEBREW_DEVELOPER=true brew install --formulae terraform.rb:

$ HOMEBREW_DEVELOPER=true brew install --formulae terraform.rb

==> Fetching downloads for: terraform
✔︎ Bottle Manifest terraform (1.3.6)
✔︎ Bottle terraform (1.3.6)
Warning: terraform 1.5.7 is available and more recent than version 1.3.6.
==> Pouring terraform--1.3.6.arm64_ventura.bottle.tar.gz
🍺  /opt/homebrew/Cellar/terraform/1.3.6: 7 files, 64MB
==> Running `brew cleanup terraform`...
Disable this behaviour by setting `HOMEBREW_NO_INSTALL_CLEANUP=1`.
Hide these hints with `HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).

Now terraform version 1.3.6 is installed!

$ terraform version

Terraform v1.3.6
on darwin_arm64

Pro Tip:

You can pin the current version so it doesn’t upgrade in the future.

brew pin terraform

The next time you run brew upgrade it will be skipped:

$ brew upgrade

Warning: Not upgrading 1 pinned package:
terraform 1.5.7

When you’re ready to upgrade, you can unpin it:

brew unpin terraform

References

• https://docs.brew.sh/Manpage
• https://docs.brew.sh/FAQ#how-do-i-stop-certain-formulae-from-being-updated

2024-10-13 Update:

I recently discovered Pearcleaner. You can use this app to delete other apps along with all the extra files and folders they create. I recommend you use this first and then continue reading this post if you want to look more deeply.

You can download Pearcleaner from the link above or install it with Homebrew:

brew install --cask pearcleaner

Searching for Residual Files and Directories

To find directories and files related to LastPass, I ran a system-wide search using find. I excluded directories such as /System/Volumes/Data since those result in errors like “Operation not permitted”. I also excluded Homebrew directories that don’t need to be cleaned up. You can add more directories as needed, just make sure to not add a trailing slash to the filepaths!

find / \
-not \( -path /System/Volumes/Data -prune \) \
-not \( -path /usr/local/Homebrew -prune \) \
-not \( -path /usr/local/Cellar -prune \) \
-not \( -path /usr/local/Caskroom -prune \) \
-name \*lastpass\* 2>&1 | grep -v -E 'Operation not permitted|Permission denied|Not a directory'

The command may take some time to complete depending on your machine specs and amount of files you have. It took around ~10 minutes for me on a 2019 MacBook Pro with an i7 Intel CPU.

Here’s the output I got from the command above. I can now go through each of these files and folders and decide if I want to delete them manually:

/private/var/folders/m9/_7bg6tbn3636m1zzlzq33bwh0000gn/T/com.lastpass.lastpassmacdesktop
/private/var/folders/m9/_7bg6tbn3636m1zzlzq33bwh0000gn/C/com.lastpass.lastpassmacdesktop
/Users/nelson/Library/Application Support/com.lastpass.lastpassmacdesktop
/Users/nelson/Library/WebKit/com.lastpass.lastpassmacdesktop
/Users/nelson/Library/Preferences/com.lastpass.lastpassmacdesktop.plist
/Users/nelson/Library/Application Scripts/N24REP3BMN.lmi.lastpass.group
/Users/nelson/Library/Application Scripts/com.lastpass.lastpassmacdesktop.safariext
/Users/nelson/Library/HTTPStorages/com.lastpass.lastpassmacdesktop.binarycookies
/Users/nelson/Library/HTTPStorages/com.lastpass.lastpassmacdesktop
/Users/nelson/Library/Group Containers/N24REP3BMN.lmi.lastpass.group
/Users/nelson/Library/Group Containers/N24REP3BMN.lmi.lastpass.group/Library/Preferences/N24REP3BMN.lmi.lastpass.group.plist
/Users/nelson/Library/Group Containers/N24REP3BMN.lmi.lastpass.group/Library/Application Scripts/N24REP3BMN.lmi.lastpass.group
/Users/nelson/Library/Containers/com.lastpass.LastPass
/Users/nelson/Library/Containers/com.lastpass.lastpassmacdesktop.safariext
/Users/nelson/Library/Containers/com.lastpass.lastpassmacdesktop.safariext/Data/Library/Application Scripts/com.lastpass.lastpassmacdesktop.safariext
/Users/nelson/Library/Caches/com.crashlytics.data/com.lastpass.lastpassmacdesktop
/Users/nelson/Library/Caches/Homebrew/Cask/lastpass--4.116.0.dmg
/Users/nelson/Library/Caches/com.lastpass.lastpassmacdesktop

This could probably be automated all the way through the deletion step, but I prefer to double check what is actually going to be deleted.

Also, this may help to free up space on macOS, but I mainly did it because I like keeping my system tidy.

Try this out with whatever apps you’ve deleted in the past. You can also try finding files and folders by specifying a company name. For example, replace \*lastpass\* with \*microsoft\* and see what you get!

References

• https://stackoverflow.com/questions/4210042/how-do-i-exclude-a-directory-when-using-find