Storing and retrieving passwords in bash scripts from the macOS keychain

It's often convenient to store a password in the macOS system keychain and retrieve it inside a shell script.

Here's the bash command for setting a password:

security add-generic-password -s "Keychain item name here" -a "username here"

Then enter your password when prompted.

After you run this once, you can retrieve the password in a script like this:

PASSWORD=`security find-generic-password -s "Keychain item name here" -a "username here" -w`

You can then use $PASSWORD whenever you need the password in your script.

Backing up OneNote notebooks

By default, OneNote stores notebooks on OneDrive in a “Documents/“ folder. But the notebooks are not downloaded locally by the OneDrive sync client — the sync client simply downloads “.url” link files that take you to the notebook on onenote.com.

However, there is an easy way to grab a backup. Use the “Download” option on onedrive.com to download a .zip file of the entire “Documents/“ folder. This .zip will have all your notebooks in the open, documented OneNote file format.


Update (November 7, 2019): Thanks to David Mytton for pointing out that this only works for personal Office365 accounts. If you have a business account, OneDrive will store your OneNote notebooks in a "Notebooks/" folder rather than a "Documents/" folder, and it will not let you download this folder. This is a known issue and Microsoft is working to resolve it.

Using Pipenv with R Markdown and reticulate

R Markdown is very nice way to write literate R code. Recently, reticulate became available, which bridges R and Python in R Markdown documents.

If you use Pipenv for Python dependency management, here's how you get reticulate to use the proper Python executable:

library('reticulate')
venv <- system("pipenv --venv", inter = TRUE)
use_virtualenv(venv, required = TRUE)
py_config()

The py_config() command should print out the path to the Python executable in the virtualenv created by Pipenv.

Ruby: Using Bundler Without a Gemfile

A very handy tip from Victor Afanasev:

Did you know that you can use Bundler inside single Ruby script (without Gemfile) and automatically install required dependencies for it?

# example.rb

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'rest-client'
  gem 'nokogiri'
end

###

body = RestClient.get("https://www.reddit.com/r/ruby/").body

puts "Posts from r/ruby front page:"
Nokogiri::HTML(body).xpath("//div[contains(@class, 'scrollerItem')]//h2").each do |h2|
  puts h2.text.strip
end

Customizing the padlock image for Curtain Mode with macOS screen sharing

By default, the Mac will display a giant padlock image when "Curtain Mode" is engaged with the Screens VNC app or macOS's built-in screen sharing capability:

I wanted to remove the padlock to avoid burn-in during long screen sharing sessions. I found this Apple Discussions post with the following instructions for overriding the default image:

  • Create a picture using a graphics program, such as AppleWorks.
  • Save the picture in PICT, TIFF, GIF, JPEG, or any other QuickTime-compatible static image format.
  • QuickTime-compatible movies or QuickTime VR objects cannot be used.
  • Name the picture "Lock Screen Picture".
  • Copy the "Lock Screen Picture" file to /Library/Preferences/ on the client computer.

I was very dubious that it would work, but incredibly it does! If you save a plain black .tiff like this one as /Library/Preferences/Lock Screen Picture.tiff, the padlock image will disappear.

Fixing files that should have been pointers in LFS but weren't

There is a relatively easy fix for a message from git lfs like:

Encountered n file(s) that should have been pointers, but weren't

If the files in question are already on a remote and you don't want to rewrite history, run:

git lfs migrate import --no-rewrite path/to/file.ext

This will create a new commit moving path/to/file.ext to LFS.

If you do need to rewrite history, see the documentation for migrating data to LFS.

To check whether this worked, run:

git lfs ls-files | grep path/to/file.ext

You should see an entry for path/to/file.ext in the resulting output.

Work-around for broken Pocket bookmarklet

I've found that Pocket's bookmarklet is not reliable in Safari and Safari Technology Preview due to browser security measures against 3rd party cookies. This results in their official bookmarklet asking me to "Please login" every time I try to use it.

Fortunately, there is an easy work-around with a very simple bookmarklet:

window.location.href = 'https://getpocket.com/edit?url='+encodeURI(window.location.href)

You can use the Bookmarklet Maker to turn this code into an actual bookmarklet.

Fix FileVault's "Some users are unable to unlock the disk" error when the APFS boot disk is manually encrypted with a "Disk Password"

This happened to me because I restored my boot disk from a full disk clone (thanks to a bad macOS update installation). I didn't want to restore to an unencrypted disk, so when I booted from my backup disk to do the restore, I used Disk Utility to encrypt my internal boot disk with a password.

After encrypting and then cloning the backup to my boot drive, I was greeted with a screen like this on my first boot from my boot drive:

Fine, no problem. I entered my disk password, and the normal login screen showed up. I entered my user password and everything was working...except I could not re-enable unlocking my disk with my user's password:

After searching around for how to fix failure of "Enable users" when "Some users are unable to unlock the disk", I discovered that there are a set of command line utilities for dealing with FileVault and I was able to fix the problem by decrypting the disk and then re-enabling FileVault.

Here's the command to decrypt: diskutil apfs decryptVolume /dev/disk1s1

To get "/dev/disk1s1", I simply looked at the info for my hard drive ("HD") in Disk Utility. (Normally this would be named "Macintosh HD", but I always rename mine.)

Then I simply re-enabled FileVault through System Preferences.

Warning: Messing around with disk encryption (or messing around with anything involving your boot disk) is risky. Always have a known good backup before you try anything like this, and proceed at your own risk – I am not responsible if you break your disk trying to follow these instructions.