From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id NV7YNkjllGLnQgAAbAwnHQ (envelope-from ) for ; Mon, 30 May 2022 17:39:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id oPikNUjllGL8ggEA9RJhRA (envelope-from ) for ; Mon, 30 May 2022 17:39:52 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5664113CA6 for ; Mon, 30 May 2022 17:39:52 +0200 (CEST) Received: from localhost ([::1]:35040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nvhUj-0003FG-Mp for larch@yhetil.org; Mon, 30 May 2022 11:39:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvhTP-0003EI-Rv for emacs-orgmode@gnu.org; Mon, 30 May 2022 11:38:32 -0400 Received: from ciao.gmane.io ([116.202.254.214]:42942) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvhTN-0002Yp-VX for emacs-orgmode@gnu.org; Mon, 30 May 2022 11:38:27 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nvhTK-0009Jm-1v for emacs-orgmode@gnu.org; Mon, 30 May 2022 17:38:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps Date: Mon, 30 May 2022 22:38:13 +0700 Message-ID: References: <963d5f94-3fdf-a01b-bc91-edc99222cb34@gmail.com> <87czgeaxir.fsf@localhost> <6615610d-93ae-171f-b554-3f4cc79354cc@gmail.com> <87a6bhc1w6.fsf@localhost> <86692975-4d5f-6933-3227-c6b208f76862@gmail.com> <877d6lbsg5.fsf@localhost> <7c75b724-1ea2-5e3e-cbe6-e1895fd35bd3@gmail.com> <877d6j2htv.fsf@localhost> <87ilq14p6p.fsf@localhost> <87v8u0396t.fsf@localhost> <87ilpz3bi0.fsf@localhost> <87h75ip5r6.fsf@localhost> <87zgj46hwo.fsf@localhost> <8735gr15ok.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US In-Reply-To: <8735gr15ok.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, 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-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1653925192; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=2vapWSGlU4RmkLQZ+OfQQaj3wKlKBjt29hGz44hQzis=; b=ESGsWx4KFJW7lTYZBySJm58MFz0lKrVMbAGr9bQM/e0z08f2hnFMP3pkTJb5Ka71p23+pE eKsjtdD0nC81HVDOKxWxcWWEisjsh18i49b7Xt3t1HKwcztZyHZkAjAFiBf8No+Xzbzdzv PeqXYKxrEVMiU1ie9J10R2jo7lMs2ibS36Q6KwfbzI9GH5vLCL/TKZAw8hGzkjXPEiyfp9 CqZytrYkvdckSRuHgu9IwKDtISn/KXFejQY/j1dWQB/7QoVC6D96umZ6npBahMe4x7szo4 +lrsnw9zSfHnyahCgBJl7yN4DGNO0KLlaeFyvtbhUQfX2peVgtZ3JzCuhhk6Eg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1653925192; a=rsa-sha256; cv=none; b=bqz6ljDkK4iTmvamzKBMBVLBo9tC2KWByFxU/VyN27Vtgypm3g7KgbzyBmd30+4uNk2Qc2 ztvgyFkItO8IZnRrl5xGjsxgpCtxnGvWnyGs1hu8RHzJ7tC4MrTrNLrBU0xIMEwS8K390G nTRXOHtuA1rDP56VU+BQMkmEknR0d7aAiRQFwLSSGR5UaHjOtLti3raDdhdmS0dLrjX3sX Qqz0O+AUz+mWbHMM5Slmudp2PNXUyGJYQlbbXa8iOZt5IumeMm3dUkxedgBn6SV0qItbo5 WCbXtV/AH2RheDpdPuj8rT4pW7xzk02PZArcZ07JG96UlvdjtVS/CRHDCN52Rg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 1.87 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 5664113CA6 X-Spam-Score: 1.87 X-Migadu-Scanner: scn0.migadu.com X-TUID: kxCjSRG5Usw4 On 30/05/2022 21:00, Ihor Radchenko wrote: > - (let* ((mime-type (mailcap-extension-to-mime (or ext ""))) > + (let* ((mime-type (if (executable-find "file") > + (shell-command-to-string > + (format "%s --brief --mime-type --dereference %s" > + (executable-find "file") (shell-quote-argument (executable-find "file")) For the case of a directory with spaces or other characters interpreted by shell in the PATH environment. Unsure if "file" command variants exist that do not support --dereference. Another pitfalls with `shell-command-to-string' is that it provides no way to handle errors. I would consider 2>/dev/null to not consider error message as MIME type and `mailcap-extension-to-mime' as fallback when "file" command fails. (let* ((file-executable (executable-find "file")) (mime-type-file (and file-executable (shell-command-to-string (format "%s --brief --mime-type --dereference %s 2>/dev/null" ; ... ))) (mime-type (if (org-string-nw-p mime-type-file) mime-type-file (mailcap-extension-to-mime (or ext ""))) > + (shell-quote-argument (convert-standard-filename file)))) > + (mailcap-extension-to-mime (or ext "")))) > Max Nikulin writes: > >> 3. With your patch and the following additional entry in ~/.mailcap >> (notice "text" instead of "application" and just "emacs") >> text/x-shellscript; emacs %s; test=test -n "$DISPLAY" >> new Emacs session is started. It is a problem but partially >> it is caused by incorrect mailcap configuration. >> Unlike "text/plain" that would be handled by view-mode >> unless `mailcap-mime-data' were erased in Emacs-27, >> "text/x-shellscript" is handled by less on my main system >> due to mailcap while I would expect same Emacs session. > > I am confused here. org-file-apps-gnu says that we rely on mailcap: > > ((remote . emacs) > (system . mailcap) > (t . mailcap)) > > So, is (3) following what you would expect from mailcap (regardless > whether it is incorrectly configured or not)? Wrong configuration of > mailcap is none of Org business - we need not to be "smart" and fix user > "errors". They may be deliberate. Ihor, I am afraid that your patch may break some subtle equilibrium existing despite discrepancy in MIME type names for shell script. Worst scenario: without the patch shell scripts are opened in the same Emacs session, with it attempt to open a script silently fails due to "less" handler requiring a terminal. I admit that your patch may improve handling of e.g. images, however it is more rare case when an image file has no suffix, while it is quite common for various scripts (shell, python, perl, etc.) I have not tried emacs-28 yet or some other full fledged desktop environment (in VM). There is no official MIME type for shell scripts http://www.iana.org/assignments/media-types/media-types.xhtml so definitions "text" or "application", "x-sh" or "x-shellscript" vary. E.g. https://wiki.debian.org/ShellScript : "The MIME type of shell scripts is nowadays text/x-shellscript but other systems may still use application/x-shellscript." Emacs uses application/x-sh for the .sh suffix. There is no association for this type in `mailcap-mime-data'. The "file" command reports "text/x-shellscript". I have neither "application/x-sh" nor "text/x-shellscript" in /etc/mailcap (Ubuntu-20.04), there are only several entries for "application/x-shellscript". That is why your patch should not make handling of shell scripts worse... till mailcap and "file" will start to use the same type. >> In some cases >> it may be handy to launch remote viewer from a host accessed through >> ssh, but let's leave it aside. > > This is exactly why you can always customize org-file-apps. I am confused by this phrase. `org-file-apps' is ignored for remote files, otherwise more care would be required for executing "file". > I added the extra argument as you suggested. See the new version of the > patch. Though my man tells me that --dereference is the default. Not on > your system apparently. I have no idea. Quick search have not provided a changelog, but I have noticed https://bugs.astron.com/view.php?id=29 >> (mailcap-extension-to-mime "sh") => "text/x-sh" >> >> run-mailcap --norun examples/org/script/tstorg.sh >> Error: no "view" mailcap rules found for type "application/x-sh" >> >> And "text/x-shellscript" as above. > > This should not matter for us. As long as mailcap-mime-info returns > something meaningful, we should be good to go. Unless mailcap-mime-info > itself is buggy. Following a link to a shell script from an org file (without customization) I expect that it is opened in the same Emacs session. Maybe my expectation is wrong and system-wide handler (gedit, kate, etc.) should be launched. It seems current status quo (at least for some linux distributions) is consistent with my expectations, but only due to inconsistency in naming of the MIME type.