Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS: problems on Big Sur (Intel) & BBEdit #22

Open
JayBrown opened this issue Feb 20, 2021 · 3 comments
Open

macOS: problems on Big Sur (Intel) & BBEdit #22

JayBrown opened this issue Feb 20, 2021 · 3 comments

Comments

@JayBrown
Copy link

So git-peek didn't work as expected with BBEdit. Config file ~/.git-peek has EDITOR=BBEdit --wait

It was working fine in iTerm, but as soon as I use the Firefox extension via the git-peek app, it failed. What I noticed was the following: the code signature of git-peek.app was broken, and it's not possible to apply a new signature, because git-peek-shim was in the wrong place within the bundle.

So I moved that file to ./Contents/MacOS/git-peek-shim, then changed its editor line to export EDITOR="BBEdit", then changed ./Contents/Resources/Scripts/main.scpt to

on open location this_URL
	try
		set innerCmd to "/Users/USER/Applications/git-peek.app/Contents/MacOS/git-peek-shim " & quoted form of this_URL & " &> /usr/local/var/log/git-peek &"
		do shell script innerCmd
	on error errMsg
		display dialog errMsg
	end try
end open location

i.e. changed the path of the variable innerCmd, whereas "USER" is substituted for my actual username, of course… then code-signed the app again, which finally worked, because git-peek-shim was now in a proper nested location. (Note: a broken signature might cause problems on Big Sur on arm64 macOS.)

Now, running git-peek via the Firefox extension opened BBEdit alright, but after the repo downloaded, it didn't show & was colored red, which in BBEdit means that a file has been deleted, in our case that the repo was deleted immediately after download.

How do I solve this problem?

git-peek via iTerm

snap1

git-peek via Firefox extension

snap2

@Jarred-Sumner
Copy link
Owner

Jarred-Sumner commented Feb 20, 2021

the code signature of git-peek.app was broken, and it's not possible to apply a new signature, because git-peek-shim was in the wrong place within the bundle.

I didn't know that executable files have to go in a particular place within the .app folder. Thanks for that. I updated the register script to write to that location instead.

Now, running git-peek via the Firefox extension opened BBEdit alright, but after the repo downloaded, it didn't show & was colored red, which in BBEdit means that a file has been deleted, in our case that the repo was deleted immediately after download.

Just pushed 1.3.18 which fixes this for BBEdit. From me manually testing, it seems to work however for some reason it opens in the background instead of the foreground when coming from the extension. I'm not sure if there's a CLI argument I can pass it that tells it to open in the foreground – happy to add it if you know of it/can link to some docs that show their CLI arguments. When I say "background", I just mean it doesn't gain focus.

If you run this, it should update:

brew upgrade git-peek

Closing but feel free to re-open if you have any more issues with BBEdit/doesn't fix

@JayBrown
Copy link
Author

JayBrown commented Feb 20, 2021

Thank you. New problem now (still not working): git-peek apparently deletes the repo, and BBEdit still doesn't show anything. stdout tells me that git-peek "deleted repository".

snap

Though BBEdit does open in the foreground on my system. That's the default behavior of open, unless you specify -g (open in background) or -gj (open in bg & hidden), so I assume that the default in-foreground behavior should also apply to other open calls.

I noticed another problem with the code signature. Whenever changing anything that's nested in the .app bundle, e.g. writing the shim or changing the Info.plist, there needs to be a deep codesigning run at the very end, something like: codesign --force --deep --sign - foo… i.e. codesign shall always come last, and re-codesign shall occur after every config change by the user, if that entails a modification of nested bundle content.

@Jarred-Sumner
Copy link
Owner

Jarred-Sumner commented Feb 20, 2021 via email

@Jarred-Sumner Jarred-Sumner reopened this Feb 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants