[opam-devel] Opam 1.2 breaks emacs on the mac sortof
yminsky at janestreet.com
Tue Sep 9 12:11:11 BST 2014
Nice! I'll look at that.
Can someone confirm that the change in how "opam config env" really
happened between 1.1.2 and 1.2? I wonder if so whether it would make
sense to revert it, since that would avoid breaking lots of emacs
configs for people, and also because the new behavior also seems worse
than the old one.
On Tue, Sep 9, 2014 at 5:09 AM, Richard Mortier <mort at cantab.net> wrote:
> On 9 September 2014 03:08, Yaron Minsky <yminsky at janestreet.com> wrote:
>> Apologies for the following bits of emacs nonsense.
>> Sadly, I think that opam 1.2 has broken the emacs configuration that I
>> documented here:
>> I'm looking for advice as to how to fix things. It has to do with how
>> paths are set up. Emacs for the mac has the annoying property of not
>> propagating ordinary shell settings. Instead what I did was this:
>> ;; -- Tweaks for OS X -------------------------------------
>> ;; Tweak for problem on OS X where Emacs.app doesn't run the right
>> ;; init scripts when invoking a sub-shell
>> ((eq window-system 'ns) ; macosx
>> ;; Invoke login shells, so that .profile or .bash_profile is read
>> (setq shell-command-switch "-lc")))
>> This caused the .profile to get run again on every incoming shell.
>> This has the property of rerunning "eval `opam config env`". That
>> used to work because opam would throw its entries on the path when it
>> ran. But I believe opam has been changed to not re-add entries when
>> they're already there. This means that when you run the shell with
>> "-lc", it redumps the entries from /etc/paths on top, thus shadowing
>> the opam entries.
> the fragment i have in my `~/.emacs`
> (https://github.com/mor1/rc-files/blob/master/emacs.d/init.el) that
> attempts to deal with this is:
> ;; <http://stackoverflow.com/questions/8606954/
> ;; path-and-exec-path-set-but-emacs-does-not-find-executable>
> (defun set-exec-path-from-shell-PATH ()
> "Set up Emacs' `exec-path' and PATH environment variable to
> match that used by the user's shell.
> This is particularly useful under Mac OSX, where GUI apps are not
> started from a shell."
> (let ((path-from-shell
> "[ \t\n]*$" ""
> (shell-command-to-string "$SHELL --login -i -c 'echo $PATH'"))
> (setenv "PATH" path-from-shell)
> (setq exec-path (split-string path-from-shell path-separator)))
> ie., extract $PATH from a shell and then set various emacs variables
> accordingly. but it's hardly pleasant.
>> We could change opam 1.2 so that instead of not adding entries when
>> they're already there, it instead deletes the old version of the entry
>> and re-adds it to the top. Or we could come up with a more principled
>> emacs-on-the-mac setup, but I can't quite figure out a good way of
>> doing that.
> well, encouraging emacs on the mac to propagate shell settings
> properly would do it for me ;)
> failing that, i like the idea of opam deleting old instances of PATH
> mods and then re-adding at the front. that seems the least surprising
> and tidiest option.
> (probably not much help for the rwo documentation, but fwiw i got
> bored of shell environment confusion a while back and wrote some shell
> functions to help me keep things clean and attempt to make shell
> initialisation largely idempotent; i basically never now have lines of
> the form VAR=value:$VAR in any of my startup scripts.
> Richard Mortier
> mort at cantab.net
More information about the opam-devel