[ With 'Reply All' ] Here's a summary of what I currently observe: 1)  I was mistaken about the change from 9.5.2 to 9.5.3.  You are correct.  As you noted, the 9.5.2, 9.5.3 diff I previously mentioned was erroneous. 2) The problem I encounter with both 9.5.2 and 9.5.3 is that when opening a shell script -- no file extension, e.g. /home/user/myscript -- mailcap should be consulted and org should open the script file in Emacs.  The mailcap entry is: application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY" But instead, org opens the script file using /bin/less, not emacs. 3) The misbehavior in #2 is new.  I don't know exactly when it started misbehaving but I suspect it happened after updating org to 9.5.3.  But other packages -- elpa, emacs binaries, OS binaries -- may have been updated at the same time, or before that, or after that, so hard to pin it down.  I can't even say for sure if the upgrade to org 9.5.3 was from org 9.5.2.  It may have been an upgrade from an org version older than 9.5.2. 4) Throughout this discussion, when I say "org opens" I am referring to the key sequence "C-c C-o" bound to org-open-at-point.  It opens script file with /bin/less, which is not what I would expect. , bound to org-open-at-mouse (which calls org-open-file?) has the same misbehavior. 5) , bound to org-find-file-at-mouse, *works as expected* and opens the script file in emacs.  Also, using a single prefix argument, "C-u C-c C-o" *works as expected* and opens the script file in emacs. 6) Last but not lease, when I *manually edit* org.el and change the last line of the org--file-default-apps function definition, removing underscore and space, and replacing with single quote like this: diff 8701c8700 <     (_ org-file-apps-gnu))) --- > ('org-file-apps-gnu))) I no longer observe the misbehavior described in #2 and #4. Instead, org *works as expected*, like it does with #5, and opens the script file in emacs, not /bin/less. I know your time is valuable.  No need for you to spend a lot of time on this if I am the only one having this problem.  It could be some random artifact in my installation, maybe something in my ~/.emacs.  My ~/.emacs has a lot in it.  And I have a work-around, since I can use #5. Best wishes, -C On 5/16/22 6:29 AM, Craig STCR wrote: > It's possible my elpa is FUBAR.  I will uninstall, rm .elc, > re-install, and re-compile org 9.5.3 when I get a chance. > > On 5/16/22 6:08 AM, Craig STCR wrote: >> OK, I'll take a look as you suggested as soon as I can. >> >> So the form in 9.5.2 was a bug? >> >> The problem I encounter with the new form in 9.5.3 is that when >> opening a shell script -- no file extension, e.g. /home/user/myscript >> -- 9.5.2 would consult mailcap and open the script in Emacs.  The >> mailcap entry is: >> >> application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY" >> >> But with the new form in 9.5.3, /home/user/myscript is opened by >> /bin/less, not emacs.  I assume mailcap is not consulted.  Which does >> not work well.  These behaviors are only for org.  Outside of org, >> emacs behaves correctly. >> >> I'll take a look as you suggested as soon as I can. >> >> Thanks, Ihor. >> >> >> On 5/16/22 4:33 AM, Ihor Radchenko wrote: >>> Craig STCR writes: >>> >>>> 9.5.3 does not return org-file-apps-gnu because org-file-apps-gnu is not >>>> quoted.  Should be (and was in 9.5.2): >>>> >>>> 'org-file-apps-gnu >>>> >>>> but in 9.5.3 it is: >>>> >>>> _ org-file-apps-gnu >>> Please try to run the following form: >>> >>> (pcase 'gnu/linux >>> (`darwin org-file-apps-macos) >>> (`windows-nt org-file-apps-windowsnt) >>> ('org-file-apps-gnu)) ;; => nil >>> >>> and then >>> >>> (pcase 'gnu/linux >>> (`darwin org-file-apps-macos) >>> (`windows-nt org-file-apps-windowsnt) >>> (_ org-file-apps-gnu)) ;; => ((remote . emacs) (system . mailcap) (t . mailcap)) >>> >>> The second case is returning a list, which org--file-default-apps >>> supposed to return. The previous behaviour was erroneous. You may refer >>> to M-x describe-function pcase to understand the code. >>> >>> Please, provide more details on the actual error you ran into. The >>> change in the org--file-default-apps is not a bug. >>> >>> Best, >>> Ihor >>> >> >