This has been reported several different times without resolution that I can find. Those threads are mostly closed due to time limits.
So trying again.
While these seem somewhat harmless, they make working with WP CLI a pain.
This has been going on for 6 months, so it’s not really version specific. There seem to bee similar reports from Win10 users, but this is on macOS 10.15.7.
3 out of 4 of these appear to be code signing issues.
If you switch to PHP 7.3.5 (bundled with Local), does it resolve the issue?
Additional context: we don’t currently codesign downloadable services in Local (bundled services are signed) as Apple was previously OK with a codesigned application downloading additional binaries. It’s looking like we’re going to need to update our build process to start signing all downloadable Lightning services.
For what it’s worth, I just tested this on my personal MBP running macOS 11.1 and a Parallels VM running macOS 11 and was unable to reproduce this even when using PHP 7.4.1. So, I think this disproves my theory of Apple tightening up codesigning restrictions like I previously thought.
I’m guessing this will return a version of WPCLI that’s manually installed as opposed to the one that’s shipped with Local.
For what it’s worth, @Xaver was having some odd interactions with the Local site due to the shell using a manually installed version of WPCLI as opposed to the one that was shipped with Local.
It’s not the same issue as this topic, but you might take a look at this topic to see if it helps with debugging what’s going on here:
I use ZSH and Oh My Zsh on iTerm2. I don’t have a .bashrc.
My .zshrc doesn’t do anything that would affect PHP that I can think of, I’ve attached just in case you want to “see” them. I can’t promise there isn’t some other setting elsewhere that could… but I looked and I haven’t installed alternative versions of PHP on this machine via brew (yet…). Haven’t had the need yet I guess. zsh-bash-profile.zip (2.6 KB)
two screenshots, starting up shell from local it runs the script that should set PHPRC, I don’t know why it doesn’t actually do that…
Do you think this could be a ZSH issue? Does that support $PHPRC? Maybe I’ll try swtiching to bash to see if this problem exist there… but ugh I hate bash
I’m having trouble replicating, but I also noticed some odd things when taking a close look at my own .zshrc as well as @jb510’s .zshrc.
Something about this that feels like a $PATH issue, possibly relating to child-shells.
I’d be curious to know what your $PATH looks like. I used this to change the colons to new lines, which I think makes it easier to read. The top lines have a higher precedent than the lower lines:
echo $PATH | tr ':' "\n"
For me, I would have thought that Local’s config would put the Local site items as a higher precedent than anything else, but in actuality, there are a few items that are “put ahead” of those folders:
I think that the reason that there are repeated items in my PATH is due to the Local shell script using exec $SHELL (ie, creating a subshell) as opposed to just sourceing the file.
@jb510 can you try sourceing the “open shell script” instead of running it as a sub-shell? Specifically do:
In Local, click “Open Site Shell”. This will create the shell script.
Edit the file that was run using “open site shell”
Comment out the last line that says exec $SHELL
Save the file
In a non-Local shell, (ie, a new one) try running that script and see how that affects the $PATH
It’s important to note that when you click the “Open Site Shell” button within Local, the shell script is regenerated, so any edits you make to that script will be wiped out if you try to open the shell from Local.
The reason to try these things is to see if the act of creating a subshell (and therefore, reloading all of the zsh config) is causing issues with how things are being loaded.
Thank you @afragen, confirmation it’s not ZSH/OMZ is a big help. Still don’t know what’s causing it, but gives me hope I can find it in configs.
@ben.turner TY for continuing to try to help with this. I too feel it’s path or permission related. I thought @clay might have been on to something with codesigning being involved.
In this screenshot left side is first run. Default with the path echoed for reference.
I then opened up the shell script in VS Code and commented out the last exec. line.
I then opened a new shell (iterm new window, right side of screenshot). I ran the script, checked which php, , checked $PHPRC which appears unset.
I ran through it a second time. New terminal session, Checked exec still commented, ran script, ran ‘export’ and again it’s showing no PHPRC set.
@afragen Does your .zshrc source .bash_profile like mine does? Entirely possible I added that years ago and forgot about it.
If it does, does your .bash_profile include sources like mine? Again, entirely possible I add those years ago and forgot about it… and possible maybe they ‘belonged’ somewhere else like .bashrc.
Nice find! I think you’ve zeroed in on what’s wrong. Taking a look through the .bash_profile file, it seems like most of the PATH related configuration is already in the .zshrc file. You can probably hand move any configuration that you need over to the zshrc file and then remove the source ~/.bash_profile line.