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.
