From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel,gmane.emacs.auctex.devel Subject: Re: [script vs ICon: latex binaries not found] (was: Emacs on macOS) Date: Mon, 04 Apr 2022 18:38:19 +1000 Message-ID: <87sfqt1aj1.fsf@gmail.com> References: <0CBBB7FB-1D2A-46C7-90C2-8664913B0E29@icloud.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38886"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.12; emacs 29.0.50 Cc: auctex-devel , EMACS development team To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 04 11:09:52 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbIie-0009wA-7q for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Apr 2022 11:09:52 +0200 Original-Received: from localhost ([::1]:49836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nbIic-00051P-Ly for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Apr 2022 05:09:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbIh2-0003At-Em; Mon, 04 Apr 2022 05:08:12 -0400 Original-Received: from [2607:f8b0:4864:20::1032] (port=56295 helo=mail-pj1-x1032.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nbIh0-00055U-Ra; Mon, 04 Apr 2022 05:08:12 -0400 Original-Received: by mail-pj1-x1032.google.com with SMTP id kw18so1922271pjb.5; Mon, 04 Apr 2022 02:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=ew2AdJL4MhNcaCWn6t+wtYA3OgVxbbioen9LrEL4He0=; b=hROs0F4JWPU6TZzLsk7eye1xNJRQss2h+zGNJmifyUN37gD6q3gH5mEr0u23gYnLxd 6/vWqyMruVamgYrAQVWAH9k+OGE4glg5eDWDGXKygg1oYxpKXehYYq2RWDVk295Y+pWH JSnW0gk7pcWJJfoB6JjLbo/y8w6bxXKlx6LyapuhSy55nbAn09FsVcx1OBaWnvycC14I dsBOZ9aRV5dlhUmwOuLqIgGnyTgqStN0G0IUz6gV9Om3C1UfqNdFRgMq6cDuJMDpVnaS km3XNCXhlUsqGWWtUUnUsWzUG7GT1N40XDhRuf5JwpaZKRqe3Yq4T7L01UyF4ln0C1sZ 5yiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=ew2AdJL4MhNcaCWn6t+wtYA3OgVxbbioen9LrEL4He0=; b=SVRjC7y4q2H9cWXsd7C3uLfnVR8dOXB6IbDxqOKAR6r22+avAcsWwzgY+qF5rA3q8z lC1tsWvlMJf+h1oW9P8UP+sVRSzwNiqVNlWg2p3ICXFApjdecOFiYJxU8BFHhG530rOH NPVzm2VArh8u5mxR4iupMKPJ7vf2nVxNMWC6M71a25y85iJwvkmcvmYPC0v+sGUZiaDj 17B9+jG3A4qCM4Dvl0weooUnJF+wIkzFQiCqTlcB2Bl7JdypoQ/JaOT+xc1OTmmVlCU1 9yXN+uPzK3eT8Yo3F8K7acTE7h0qASeomMEopyvafOdJsNX/yxYZUbOmdcaPOvKy9fcF Chdg== X-Gm-Message-State: AOAM533xp+BbeUcS8KV9qbfOH5C+RisI3Xsc06RXWFX8anMrBdGTbMmz adPOQkkn3Ps9Ou+vuN+fIVXnjseJXRc= X-Google-Smtp-Source: ABdhPJyaXiKDL+nSprGSaJW45MQp2RPGIkyu8azosZCxm/UJAkTmsLgT1gpw8XRwfSPPbz2blia54w== X-Received: by 2002:a17:903:1248:b0:151:9708:d586 with SMTP id u8-20020a170903124800b001519708d586mr22338041plh.15.1649063287502; Mon, 04 Apr 2022 02:08:07 -0700 (PDT) Original-Received: from dingbat (220-235-26-154.dyn.iinet.net.au. [220.235.26.154]) by smtp.gmail.com with ESMTPSA id bv8-20020a056a00414800b004fafb37f293sm10732635pfb.209.2022.04.04.02.08.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 02:08:07 -0700 (PDT) In-reply-to: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::1032 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::1032; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1032.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:287742 gmane.emacs.auctex.devel:6664 Archived-At: chad 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).