When launching the executable through a symbolic link, the application is started differently, i.e., outside of the application bundle. This disconnects the command-line tool from the information property list (Info.plist). When trying to access the main bundle of the application in
|
Bundle.main.bundleIdentifier! + ".ContentBlocker" |
the process fails to detect the bundle identifier, which is usually obtained from the default information property list. This causes a forced unwrap of
nil and crashes the process.
Related questions on Stack Exchange (unanswered at the time of writing):
Ideas
Usually, the information property list can be embedded into the executable itself, e.g., to enable the App Sandbox for command-line utilities, see https://stackoverflow.com/a/60282941/5082444. Simply enabling the corresponding Xcode setting did not create the respective section in the binary, though.
As explained in a601899, creating a separate command-line executable will not work either.
Workarounds
- Use an shell alias instead of a symbolic link, as suggested in the README.
- Create a wrapper script somewhere in
PATH:
#!/bin/sh
'/Applications/Blocki.app/Contents/MacOS/Blocki' "$@"
When launching the executable through a symbolic link, the application is started differently, i.e., outside of the application bundle. This disconnects the command-line tool from the information property list (
Info.plist). When trying to access the main bundle of the application inblocki/BlockiKit/Blocki.swift
Line 13 in 4e918e5
the process fails to detect the bundle identifier, which is usually obtained from the default information property list. This causes a forced unwrap of
niland crashes the process.Related questions on Stack Exchange (unanswered at the time of writing):
Ideas
Usually, the information property list can be embedded into the executable itself, e.g., to enable the App Sandbox for command-line utilities, see https://stackoverflow.com/a/60282941/5082444. Simply enabling the corresponding Xcode setting did not create the respective section in the binary, though.
As explained in a601899, creating a separate command-line executable will not work either.
Workarounds
PATH: