Emacs on macOS

Emacs on macOS

[Perry Smith]

I’m not sure if this is the best list for this:

I have an M1 Max (arm based / Apple Silicon) MacBook Pro with the latest macOS of 12.3.  I also have Homebrew installed with about 27 items installed.  I have not installed any libraries just to have the libraries but have only installed commands.

In any case, building emacs was the usual drop dead easy: ./configure; make ; make install

The one tiny hiccup is you need to do:

sudo xattr -rds com.apple.quarantine Emacs.app

to get the Emacs.app to launch.  The GNU Emacs web site points users to EmacsForMacOSX.  EmacsForMacOSX has problems opening files in ~/Desktop, ~/Downloads, and ~/Documents if the user is using Apple’s cloud solution.  My belief is that these problems come up because the EmacsForMacOSX starts with a ruby script which eventually launches the emacs binary.  I believe macOS at that point no longer trusts the executable — which seems totally reasonable.

Now… for my question:

When emacs dies on a Mac (as with any application), a GUI window pops up with a place to enter some text and a button that says “Report”.  When the button is hit, something sends something somewhere but I doubt if anything is sent to the emacs-bug list.  The window appears to have some pretty useful information like stack trace for each thread, etc.

The flip side is, report-emacs-bug also has a lot of useful information.  My question is what is the preferred or most effective way to combine these two sources of information?  One choice is to copy what is in the macOS window and paste it into the email that report-emacs-bug creates.  Another choice might be to attach a file that macOS creates when an application dies but I don’t know where that file lives.

Thank you for your time
Perry

Re: Emacs on macOS

[Po Lu]

Perry Smith <pedzsan@icloud.com> writes:

> When emacs dies on a Mac (as with any application), a GUI window pops
> up with a place to enter some text and a button that says “Report”.
> When the button is hit, something sends something somewhere but I
> doubt if anything is sent to the emacs-bug list.  The window appears
> to have some pretty useful information like stack trace for each
> thread, etc.
>
> The flip side is, report-emacs-bug also has a lot of useful
> information.  My question is what is the preferred or most effective
> way to combine these two sources of information?  One choice is to
> copy what is in the macOS window and paste it into the email that
> report-emacs-bug creates.  Another choice might be to attach a file
> that macOS creates when an application dies but I don’t know where
> that file lives.

When Emacs crashes, it should output a backtrace to stdout.  The correct
thing to do is to ignore the contents of any macOS system error dialog,
convert the backtrace to human-readable form, and send that backtrace to
bug-gnu-emacs along with the output of `report-emacs-bug'.

See (emacs)Crashing for more information on how to do this.

Re: Emacs on macOS

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 01 Apr 2022 15:55:05 +0800
> 
> When Emacs crashes, it should output a backtrace to stdout.

Except that on some window-systems, a GUI application has its stdout
sent to the great void.  (I don't know if this happens on macOS.)

[Add xattr to the INSTALLATION file?] (was: Emacs on macOS)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

>>> "PS" == Perry Smith <pedzsan@icloud.com> writes:

Hi
> I’m not sure if this is the best list for this:
> I have an M1 Max (arm based / Apple Silicon) MacBook Pro with the
> latest macOS of 12.3. I also have Homebrew installed with about 27
> items installed. I have not installed any libraries just to have the
> libraries but have only installed commands.

> In any case, building emacs was the usual drop dead easy: ./configure; make ; make install

> The one tiny hiccup is you need to do:

> sudo xattr -rds com.apple.quarantine Emacs.app

> to get the Emacs.app to launch. The GNU Emacs web site points users to
> EmacsForMacOSX. EmacsForMacOSX has problems opening files in
> ~/Desktop, ~/Downloads, and ~/Documents if the user is using Apple’s
> cloud solution. My belief is that these problems come up because the
> EmacsForMacOSX starts with a ruby script which eventually launches the
> emacs binary. I believe macOS at that point no longer trusts the
> executable — which seems totally reasonable.

Very interesting, I compiled GNU emacs on Mac 10.15 myself, but using
fink [1]. Be it as it may I did not use xattr (I did not know about
about it, so I used the ruby script to start my compiled emacs. Well it
is quite slow (reason could also my init file), so

How does your compiled Emacs start up? Since you have a M1 it should be
fast, but did you compare it with the rugby script?


BTW, maybe 

sudo xattr -rds com.apple.quarantine Emacs.app

should be added to the INSTALLATION file for MacOS?



Regards

Uwe Brauer 

Footnotes:
[1] (because I thought it would be more familiar to a debian system, it
     is but a bit outdated, well with two maintainers, no wounder)


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Emacs on macOS

[Alan Third]

On Thu, Mar 31, 2022 at 05:52:01PM -0500, Perry Smith wrote:
> When emacs dies on a Mac (as with any application), a GUI window
> pops up with a place to enter some text and a button that says
> “Report”. When the button is hit, something sends something
> somewhere but I doubt if anything is sent to the emacs-bug list. The
> window appears to have some pretty useful information like stack
> trace for each thread, etc.
> 
> The flip side is, report-emacs-bug also has a lot of useful
> information. My question is what is the preferred or most effective
> way to combine these two sources of information? One choice is to
> copy what is in the macOS window and paste it into the email that
> report-emacs-bug creates. Another choice might be to attach a file
> that macOS creates when an application dies but I don’t know where
> that file lives.

I'd suggest your copy/paste option. Or if the output from the macOS
window is very large attach it as a file.

The output from the macOS window can be of no use or a lot of use,
depending on what caused the crash, and sometimes how the build has
been done, but it's usually better than nothing.
-- 
Alan Third

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

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

>>> "PS" == Perry Smith <pedzsan@icloud.com> writes:

> I’m not sure if this is the best list for this:
> I have an M1 Max (arm based / Apple Silicon) MacBook Pro with the
> latest macOS of 12.3. I also have Homebrew installed with about 27
> items installed. I have not installed any libraries just to have the
> libraries but have only installed commands.

> In any case, building emacs was the usual drop dead easy: ./configure; make ; make install

> The one tiny hiccup is you need to do:

> sudo xattr -rds com.apple.quarantine Emacs.app

> to get the Emacs.app to launch. The GNU Emacs web site points users to
> EmacsForMacOSX. EmacsForMacOSX has problems opening files in
> ~/Desktop, ~/Downloads, and ~/Documents if the user is using Apple’s
> cloud solution. My belief is that these problems come up because the
> EmacsForMacOSX starts with a ruby script which eventually launches the
> emacs binary. I believe macOS at that point no longer trusts the
> executable — which seems totally reasonable.

Ah well, I run some tests. With your proposed xattr command, when
clicking on the Emacs icon, then I cannot access these three folders,
without further confirmation. When I start it via the script that
problem does not occur (I recall vaguely that I have to configure the
security setting of the Mac).

I found another strange problem (curious what other think), when
clicking on the icon and starting Emacs this way, then I have the
following problem.

Using auctex in a latex buffer auctex does not find the executable latex
binaries (I have Mac Latex installed with is basically texlive), while
it does when I start emacs with the rugby script. Not sure how is the
culprit here. I put the auctex-devel on the CC

Uwe Brauer 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

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.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

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). 

Re: [script vs ICon: latex binaries not found]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]


> chad <yandros@gmail.com> writes:


> 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. 

Very much so.


> 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!).

Oops so do I (I even use the tcsh shell (via fink)


> 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.

That is important to know, thanks


> 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

I'd rather prefer not to mess up with these files, or only as a method
of last resort.

> 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). 

Right I think I will give that exec-path-from-shell a try.

Thanks

Uwe 


-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: [script vs ICon: latex binaries not found]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

>>> "c" == chad  <yandros@gmail.com> writes:

> 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,

I am not really a MacOS user (although it is much better than MS
windows) I prefer GNU/Linux, but since I also use frequently an iPad, a
Mac is useful to say the least.



> 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.

That is a good suggestion, thanks. I will give it a try.

Uwe 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]