Open Site Shell not working macOS Big Sur

Thanks for that extra info @dgwatkins!

So it sounds like the script was created, but Local didn’t automatically open a terminal for you, is that correct?

A couple of things I’m curious about and would love clarification on:

  • Was a terminal opened and quickly closed, for example, did you see a flash of a window opening and closing, or did the terminal never actually open in the first place?

  • What terminal software are you using? ie. the built-in terminal.app or something else like iterm2.app?

  • What shell are you using? ZSH? Bash? other?

As a side note, when I google macos big sur terminal not opening there are some hits, but most of them talk about the window opening, but the shell not actually being initialized.

Yes, that sounds right.

  • There is no flashing. I tried with a Terminal already open, expecting a new tab. And I tried completely closing the Terminal. In both cases there was no flash.

  • I use the Terminal built-in app

  • I’m using zsh (with oh-my-zsh) but it was working fine until last update from you (a few days ago).

The thing is that I installed macos beta more or less at the same time that I updated Local to the latest version. So I am not sure which one of the 2 updates caused the issue.

Hi there,

I have the same issue!!

Any help would be greatly appreciated.

Hey @mrajasays, Welcome to the Local Community Forums!

As of right now, this appears to be an incompatibility between Local and Big Sur, but I’d love for you to answer the same questions I asked above so that we get a better idea for the real-world settings that are in place:

Hey Ben :wave:
I know Big Sur is still in beta, so I’ll keep poking around for a workaround. But I wanted to mention that I’m having the same problem, so +1 to this bug.

-Jack

Thanks for all the feedback everyone – we have some work planned to take a closer look at these things, but I don’t have an ETA for when it will be worked on and fixed.

In the meantime, I hammered out this shell mess to hopefully allow you to work around this limitation. Basically it allows you to quickly find which shell script you need to run in order to get the environment scaffolded up:

find ~/Library/Application\ Support/Local/ssh-entry/*.sh -exec grep -H 'echo -n -e' {} \; | sed -E 's/^(.*):.*;(.*)Shell\\.*/\2 @ "\1"/' | column -s '@' -t

It might make sense to save that to a file within your path so that you can access it from anywhere:

3 Likes

Thanks for that Ben.

It works much quicker than my current solution (open dev-tools, inspect elements to find the site-id)

One gotcha I didn’t mention – these site-shell scripts aren’t created when the site is created. You’ll still need to click the “Open Site Shell” so that it creates that script initially.

From there, the above shell command I posted should get you all of the shells for your sites.

I’m working with last Local version (5.9.2+5056 )and final Big Sur version (11.0.1) and same issue. Workaround with shell script works well.

Hey this topic was two months ago. IT seems the problem persists even past beta. I cant get the site shell to open and I just updated to Big Sur today. Using Version 5.9.2+5056 and MacOS 11.0.1

@ben.turner it seems that Local never cleans up deleted sites, consequently this script can become quite unwieldy with all the results. But thanks, as it works. <3

1 Like

Oof. I can see how that gets ugly. I don’t have a fix, but doing a little CLI monkeying around with jq, I can see that at the very least on my machine, I don’t have any orphans – ie, shell scripts that don’t have a corresponding entry in the sites.json file:

Maybe some of these commands can help others with cleanup?

cd ~/Library/Application\ Support/Local
ls ssh-entry
ls run # each local site's runtime environment
jq -r 'keys[]' sites.json
comm \
        <(jq -r 'keys[]' sites.json | sort) \
        <(find ssh-entry -maxdepth 1 -mindepth 1 -type f -name '*.sh' | sed -E 's/ssh-entry\/(.*).sh$/\1/' | sort)

But that cleanup definitely would get tedious, so it might be easier to nuke everything and start over – which is what I end up doing every month or so with the amount of QA I do related to odd, broken sites.

Note, that comm can be used to only show one of those “columns” so to only see entries that only exist in that second list (ie .sh files), you should be able to do something like this to “suppress the first and third columns”:

comm -13 \
        <(jq -r 'keys[]' sites.json | sort) \
        <(find ssh-entry -maxdepth 1 -mindepth 1 -type f -name '*.sh' | sed -E 's/ssh-entry\/(.*).sh$/\1/' | sort)

Again, none of this actually cleans anything up, it just is meant to help you zero in on what might not actually exist anymore.

For the feature request, removing the specific site shell scripts on a Delete of the site would be great.

Any ETA of ‘Open Site Shell’ fix for Big Sur?

Regards.

Bumping this. Also wondering if this will be fixed soon.

I’m experiencing this issue as well. Clicking on ‘Open Site Shell’ doesn’t do anything, visually at least.

This is the biggest issue I’m having with Big Sur and on Apple Silicon.

Thanks for all the comments and adding your voices to this thread.

The team has been fixing a few other bugs and implementing a few features that should make Local easier to extend so we don’t have a specific ETA for when this issue with opening the site-shell will be fixed. We’ll be sure to update this thread when a fix has been released!

3 Likes

Are there any updates about it?

1 Like

@ben.turner Are “new features” more important than fixing broken functionality? That seems backwards? There are several large issues that are not being fixed (this issue, macOS database connection, Imagick not installed) to prioritize new functionality, and that’s very disappointing. Please prioritize the fixing of existing yet broken functionality before introducing new features.