Closed orefalo closed 11 months ago
This is likely an issue with homebrew where it stores things in weird locations and then updates $PATH itself. I bet if you launch murex from zsh then it will work (because murex would inherit $PATH from zsh)
I've got a workaround https://github.com/lmorg/murex/blob/master/config/defaults/profile_preload.mx but if you're experiencing this issue then it's likely one of those conditions isn't being met.
If you take a look at the above script and see what's failing, I can apply that fix to Murex.
Right, I can confirm an environment issue with brew, that's fine.
What I am pointing at, is that when .murex_preload
is evaluated, if it changes a env variable, the rest of the scripts are not picking it up.
They definitely are. This is exactly why .murex_preload
was created and is how I have all my machines set up.
$PATH
from the terminal (ie after .murex_preload
has run)?which jump
For me, on macOS, jump
points to /opt/homebrew/bin/jump
, which isn't in either of your $PATH's. Which would be why Murex cannot find those executables.
Laurence,
You have a M1 Mac, murex works also perfectly for me on this machine -
But on Intel Mac, brew installs its executables under /usr/local/bin - which for some reason is not set by default. This by itself will most likely solve the issue... but still, I can't explain why murex can't find the executable once PATH is properly set.
By now, I have confirmed that
.murex_preload
scriptout $PATH
. It's fine.. Now, for some weird reasons, this validation fails
for _, cmd := range m.Dependencies.Required {
if !(*autocomplete.GlobalExes.Get())[cmd] && lang.GoFunctions[cmd] == nil && !lang.MxFunctions.Exists(cmd) {
message += " * Missing required executable, builtin or murex function: `" + cmd + "`" + utils.NewLineString
}
}
I still believe you have a bug.. but I am making progress
I now understand why it works on M1 and not Intel. For some obscure reason, I have this file on M1 and not on Intel...
# ~/.profile
eval "$(/opt/homebrew/bin/brew shellenv)"
when running the command you get
➜ /opt/homebrew/bin/brew shellenv
export HOMEBREW_PREFIX="/opt/homebrew";
export HOMEBREW_CELLAR="/opt/homebrew/Cellar";
export HOMEBREW_REPOSITORY="/opt/homebrew";
export PATH="/opt/homebrew/bin:/opt/homebrew/sbin${PATH+:$PATH}";
export MANPATH="/opt/homebrew/share/man${MANPATH+:$MANPATH}:";
export INFOPATH="/opt/homebrew/share/info:${INFOPATH:-}";
that'll be your problem. You can see homebrew is updating your $PATH
and that path isn't being set by your murex profiles. So it's not that the profiles aren't retaining $PATH env correctly, it's that they don't include every required path.
Murex should detect homebrew and run that shellenv
function automatically though. Can you run the following:
if { os darwin && g /opt/homebrew/bin/brew } then {
out "woopwoop"
}
I had to change the PATH
if { os darwin && g /usr/local/bin/brew } then {
out "woopwoop"
}
woopwoop
At this point, I believe it's an OSX security feature.
there is a good reason brew went from /usr/local/bin
to /opt/homebrew/bin
anyways.. think I will just remove the dependencies to let it pass on this platform.
leave the dependencies in. I'll just update the above code to check in both /opt and /usr/local
https://www.reddit.com/r/MacOS/comments/jw9guu/why_did_homebrew_move_from_usrlocalto_opthomebrew/
I am running out of ideas....
Right, try now. The homebrew compatibility layer is this:
if { os darwin && %[ /usr/local/bin/brew ] -> f +x } then {
/bin/zsh -c 'eval "$(/usr/local/bin/brew shellenv)"; env' \
-> grep -Ei "(HOMEBREW|PATH)" \
-> prefix "export " \
-> source
}
if { os darwin && %[ /opt/homebrew/bin/brew ] -> f +x } then {
/bin/zsh -c 'eval "$(/opt/homebrew/bin/brew shellenv)"; env' \
-> grep -Ei "(HOMEBREW|PATH)" \
-> prefix "export " \
-> source
}
I don't have an intel mac to test this on so relying on your feedback
it works! thanks for the quick fix.
it's not old versions of osx, I am on the latest Ventura 13.5.1. As per the link above - brew executables are not universal. For this reason they picked a different folder for the two different architectures - intel and arm
ahhhh
I am reopening this ticket.
I may have found a way around zsh
brew shellenv -> sed 's/${PATH+:$PATH}/:$PATH/' -> \
sed 's/${MANPATH+:$MANPATH}:/:$MANPATH/' -> \
sed 's/${INFOPATH:-}/$INFOPATH/' -> source
PS1: can't believe it was so simple
PS2: the following code doesn't work with regexp
, can't explain why
brew shellenv -> regexp 's/${PATH+:$PATH}/:$PATH/' -> \
regexp 's/${MANPATH+:$MANPATH}:/:$MANPATH/' -> \
regexp 's/${INFOPATH:-}/$INFOPATH/' -> source
Seems it doesn't run if it detects it's already run. Also it tries to detect what shell you're using, if you don't specify one yourself.
% /opt/homebrew/bin/brew help shellenv
Usage: brew shellenv [bash|csh|fish|pwsh|sh|tcsh|zsh]
Print export statements. When run in a shell, this installation of Homebrew will
be added to your PATH, MANPATH, and INFOPATH.
The variables HOMEBREW_PREFIX, HOMEBREW_CELLAR and HOMEBREW_REPOSITORY are
also exported to avoid querying them multiple times. To help guarantee
idempotence, this command produces no output when Homebrew's bin and sbin
directories are first and second respectively in your PATH. Consider adding
evaluation of this command's output to your dotfiles (e.g. ~/.profile,
~/.bash_profile, or ~/.zprofile) with: eval "$(brew shellenv)"
The shell can be specified explicitly with a supported shell name parameter.
Unknown shells will output POSIX exports.
I think the best option would be seeing if we can get murex added to shellenv so then it's as simple as:
/path/to/brew shellenv murex -> source
I am reopening this ticket. I may have found a way around
zsh
brew shellenv -> sed 's/${PATH+:$PATH}/:$PATH/' -> \ sed 's/${MANPATH+:$MANPATH}:/:$MANPATH/' -> \ sed 's/${INFOPATH:-}/$INFOPATH/' -> source
PS1: can't believe it was so simple PS2: the following code doesn't work with
regexp
, can't explain whybrew shellenv -> regexp 's/${PATH+:$PATH}/:$PATH/' -> \ regexp 's/${MANPATH+:$MANPATH}:/:$MANPATH/' -> \ regexp 's/${INFOPATH:-}/$INFOPATH/' -> source
possibly because $
, +
and {}
tokens have special meanings in regex:
$
: denotes end of line+
: matching one or more of the preview match{...}
: denote repetition of the previous matcheg
(bar){3}$
would match: foobarbarbar
but not foobar
.(bar)+$
would match: both foobarbarbar
and also foobar
So if you want $
, +
and {}
to be matched as characters rather than tokens, you need to escape them, eg '\$\{MANPATH\+:\$MANPATH\}:
As for why it worked in sed
, I don't know about that. It's a different regex engine so it might be more lenient with malformed regex expressions. eg having $
at the start of the line and {...}
that contain non-numeric characters. This might also be a behaviour that isn't portable (GNU sed does behave differently to BSD sed in a number of ways).
Describe the bug: murex-module's dependency validation can't find executables, I can confirm they are in PATH Looks like Murex does not re-read the ENV variables post
.murex_preload
evaluationExpected behaviour: A clear and concise description of what you expected to happen.
Screenshots:
Additional context
So this is a weird issue, which seems to be platform dependent. I won't call it a bug, b/c I can't confirm the issue is murex.
I have two mac on the same OS version. one is Arm M1, the other Intel. the major difference between the two is that brew installs in different folders ... and also configures the default path differently - I just figured out the source of the issue ;-)
But here is the core of the issue... While debugging, I created this script
turns out, it didn't solve the issue. like if murex didn't read the new environment variable.