See also command lines it is tedious to remember for general unix/macOS/BSD/etc commands.
Most of these commands are supposed to be run sudo root, and each may irremediably erase your data, the data of your friends, the data of your enemies, and/or the data of complete strangers. I will not be responsible if you interpret this as advice, and you take it and find that you need to go running to the NSA to restore your messages from their backups.
(This was split off from general macOS hacks.)
Trash bin from the command line
AFAICT tehre are two interchangeable options
brew install macos-trash
TRIM and SSDs
If you have upgraded or replaced the SSD in an Apple computer, it will need to be TRIM-enabled for performance and lifespan. Note that Samsung models below 860 in particular are suspect, and probably should not be TRIMmed.
sudo trimforce enable
How do I rsync between macOS and Linux?
Two problems here:
- macOS seems to present weird encoding normalisation
- macOS desktop filesystems are per-default case insensitive and many other modern filesystem are case sensitive.
Both these can lead to confusing file mangling and potentially data loss.
It seems to work better for me if I do rsync from the non apple machine as far as the (2) stuff goes, in that it then seems not to accidentally duplicate things if renames have happened. I should look into this with more precision.
Then you still need to handle the encoding:
Putting that together
rsync --delete \ --iconv=UTF-8,UTF8-MAC -avz \ mac.local:/path/to/stuff/ /Volumes/syncdrive/
iconv options are in order
(Q: How does that work when both are local or both remote but you want different
The best way to make sure nobody reads your confidential data is to make sure you never store it in the first place. Fortunately, there is a solution here - FileVault 2! The encrypted external drives can be delicate. Expect the entire disk full of backups to become unusable next time the cable jiggles, and all your data will be, uh… securely deleted for your convenience.
If you like your data, keep at least two copies, on two different disks, to compensate for this convenience.
But you need to take one more step;
in periodically reformatting whichever drive most recently corrupted itself and cloning it,
you might find that you can’t even erase it.
Instead you will get an error
unable to delete core storage logical volume.
diskutil cs list diskutil cs deleteVolume <UUID> diskutil cs delete UUID-OF-COREVOLUME-GROUP
That doesn’t work? Boot into Linux and nuke it that way.
Or try this cowboy option:
cat /dev/random > /dev/diskBLAH ^C
Rebuild Spotlight index
Is Spotlight working?
sudo mdutil -sv /
No? Turn it off and on again
sudo mdutil -E /
Mounting foreign files systems
What do you have to do to get foreign filesystems to mount using this week?
osxfuse is the infrastructure providing access to a bunch of other file systems. It recently become closed source in a controversial and mildly suspect manner.
Built upon osxfuse are a variety of filesystems of varied quality.
Burning bootable ISO images to USB
Convert ISO to DMG:
hdiutil convert -format UDRW -o something.img \ something.iso
Find which disk is which:
Say it was /dev/disk3… Unmount and clobber the right one (careful now) with the new dmg:
diskutil unmountDisk /dev/disk3 dd if=./debian-6.0.7-amd64-netinst.img.dmg of=/dev/rdisk3 bs=1m diskutil eject /dev/disk3
Doing this without intermediate dmg output left as an exercise for the premature optimizer.
Filesystem updates never triggered
OS X FSEvents bug may prevent monitoring of certain folders OS X has a rarely-occurring bug that causes some folder to get ‘broken’ with regards to file system change monitoring via FSEvents. […]
In case you wonder, the bug is related to case (in)sensitivity of the file system. For certain folders, either realpath or FSCopyAliasInfo APIs report their names in incorrect case. This somehow causes the FSEvents system (used by LiveReload to monitor file system changes) to never report any changes for those folders and their subfolders.
(If you are really curious, more details can be found in Radar #10207999, in rb-fsevents issue #10 and in find-fsevents-bug repository.)
Note: this is not a “rarely occurring bug” in the sense that it sometimes occurs when you capitalise a letter in a filename; AFAICT it is triggered every time. Rather, it is a rarely noticed bug, since I guess either changing capitalisation or running file watchers, or the intersection thereof, is rarely noticed. Regardless, the above diagnoses seem to hold. Delete the offending folder and copy it from elsewhere.
extended attributes for users
ls -al@ xattr -l