Re:The -a to -z of Command-Line Options (2003)
by derefr on Friday December 14, 2018 @03:54PM
(#18684653)
Back before the Unix-ization of macOS, there was a large focus on programs providing accessibility/automation APIs. The GUI parts of macOS were actually far more scriptable back in the OS7-9 days (and early OSX days) than they are today. It used to be that any effect you wanted to trigger in the OS, you could do by sending an https://en.wikipedia.org/wiki/Apple_event through the OSA scripting component to the relevant system service.
Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more.
(Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)
Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more.
(Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)