I recently switched to the Fish shell. This has meant that the built in Open Site SSH
command no longer works. I already had my own lbf
command that figured out what site I meant to SSH into by what folder I’m currently in and drop me in that site’s SSH prompt. I’ve since rewritten that for Fish for myself, and frankly used that more than the contextual menu item in Local by Flywheel anyway. But this exposed a bug in that contextual menu item… You should be specifying what shell you want the Open Site SSH
script to use, so that it will use Bash and work properly even if the user’s shell is not Bash. As it is, my own custom lbf
function works again now that I’m not calling your scripts and rather doing what they did myself, but those scripts provided by Local still fail because they happily assume they’re in Bash, even if they aren’t. This seems like a bug that should be fixed.
Doesn’t seem like a bug, more like a limitation, and your point is fair… But I feel this could be in Feature Requests
Any chance you could share your workaround? I’m having the same issue with Fish.
I have a PHP script that parses Local’s sites.json
file to figure out what container I’m within the folders of:
// get the current working directory of where the script was called from
$cwd = $argv[1];
// get all local site settings
$local_sites = json_decode(file_get_contents($argv[2] . "/Library/Application Support/Local by Flywheel/sites.json"), true);
// recurse through directories looking for container
function find_container($path, $site) {
$path_parts = pathinfo($path);
if ($path_parts['dirname'] == $site['path']) {
return $site['container'];
} else if ($path_parts['dirname'] != '/') {
return find_container($path_parts['dirname'], $site);
} else {
return null;
}
}
// loop all sites and create map to ids
foreach($local_sites as $id => $site) {
$container = find_container("$cwd/trick", $site);
if ($container) {
echo $container;
return;
}
}
I then use that in this Fish function that I’ve put within my Fish config folder:
function lbf
# get the LBF container id using the PHP script from the Bash lbf-container
set container (command php $HOME/bin/lbf-container/lbf-container.php $PWD $HOME)
if test -n "$container"
# if we have a container attempt to enter it's bash shell
eval ("/Applications/Local by Flywheel.app/Contents/Resources/extraResources/virtual-machine/vendor/docker/osx/docker-machine" env local-by-flywheel)
"/Applications/Local by Flywheel.app/Contents/Resources/extraResources/virtual-machine/vendor/docker/osx/docker" exec -it $container /bin/bash
else
# if we don't have a container just alert the user of that
echo "Not a Local by Flywheel site folder."
end
end
Hmm, your point is correct. But maybe with the news of macOS’ default shell switching away from Bash in Catalina this indeed does become more of a bug that needs fixing. As it stands now, after Catalina anyone who installs Local on a new Mac setup will find this feature failing.
Hey @alexclst,
Thanks for bringing this up!
I honestly don’t know much about Fish but in any case I’ve added this to our backlog to dig into. We’re reworking how shell/SSH entry works with the Local Lightning release so it may be an opportune time to build in support for Fish.
By the way, nice job writing that script
I’ve now migrated to the Local Lightning public beta. Same problem. Looking at the shell-entry script (which, BTW, does very little for me as opposed to just basic cd since PHP, MySQL, and WP-CLI are all on my standard PATH anyway, so in fact I don’t even need my scripts noted above any longer) I realize that just adding a shebang to force it to run in Bash is probably all you really need. Of course, path to Bash is likely different on different platforms, and with Catalina it not being the default shell and all… But that should be all that is needed to make the Open Site SSH work regardless of the user’s chosen default shell.