Re: [script vs ICon: latex binaries not found] (was: Emacs on macOS)

[Tim Cross]

chad <yandros@gmail.com> writes:

> The point of the ruby script is to set up paths and before launching the 
> actual emacs binary, since starting a gui app
> under macOS doesn't do most of the things that a unix-based application like 
> emacs probably expects. (To be fair,
> there's only about 60 years of precedent built up, so...)
>
> The other side of the coin is this: macOS uses an ever-tightening security 
> system that is intended to prevent users from
> unintentionally running "dangerous" processes. I stopped using macOS before 
> the current generation of these
> systems, but they do fairly typical security-system things, including 
> restricting access to parts of the file system and
> refusing to run/hampering unsigned/untrusted binaries. There is a way to tell 
> the system "yes, I know emacs isn't
> security-blessed; run it anyway" -- that's (I presume) what that xattr 
> command does. Wrapper scripts present a new
> problem: are you security-blessing emacs, the wrapper script, or both? Just 
> saying "yeah, any ruby script can run
> whatever it wants" is probably not the sort of operation that the OS security 
> team wants to make trivial.
>
> As an alternative to the wrapper-script approach, there used to be an emacs 
> package that helped with some of these
> issues. IIRC, it's currently called exec-path-from-shell. 
>

I think the aspect which confuses most people under macOS is that the
'dock' does not run as a child process of the user's login shell. This
means it does not see any of the environment variables (such as PATH)
which the user may have added to in their login .profile. Common
complaint is that everything seems to work when they run Emacs from
within a terminal, but not when they start it via the 'Icon' (either
from the 'Applications' view in finder or the dock). It works from
within the terminal because the terminal has run a shell which has
sourced their login profiles (for simplicity, I'm ignoring the
subtle differences between .profile/.bash_profile and .bashrc or
.zprofile and .zxhrc, especially as lots of people now put many
environment settings in .bashrc rather than .profile these days. Same
with the differences between configuring the terminal app to run a login
shell or just a 'normal' shell i.e. there is some devil in the details!).

The macOS does add numerous additional restrictions on what applications
it will allow to be executed/run and on which folders it is allowed to
access/modify. While I'm not using the latest macOS version (actually,
not running much macOS these days at all), my experience has been that
the OS is pretty good at guiding the user on how to
enable/updatge/modify the restrictions to allow applications like Emacs
to have access. Where things fall down is that often the questions it
asks or the directions it gives to enable access can seem somewhat
oblique to some users and because they don't really understand what
either they are being asked to permit or why they should modify certain
settings, will adopt a conservative position and say no or fail to make
the configuration change. This is often made more confusing because at
the time when the user is alerted to the restrictions, things can appear
to be working and it is only later they notice issues.

The xattr command has little to do with the security restrictions on the
mac. In fact, even GNU Linux has the xattr command. The restrictions
added by macOS are a whole additional layer.

The exec-path-from-shell package is a common mechanism used to ensure
the path is configured to include additional directories and is
primarily needed because starting Emacs from the dock or Applications
folder does not run the process as a child of the user's login shell.
Another approach is to add the paths to either the /etc/paths or put
them in a file in /etc/paths.d, which sets the system wide paths which
all applications will then see. Of course, this doesn't solve the issue
of other environment variable settings which might be needed. For
simplicity, I will often just add these directly in my init.el, but this
isn't optimal as now you have two places to maintain such things (from
memory, I think the exec-path-from-shell package can help with these
more general non-path environment settings as well).