Slow start-up of shell script extensions

PopClip Extensions
1

Hi - I am new to this forum, although I have some experience creating several PopClip Extensions for my personal special purposes. And I know that I am very late to this thread :grinning:. I have the following PopClip extension for the GoToFile app calling a built in executable to execute a search on the currently selected project (i. e. folder mix). It’s exceedingly simple and works in principle:

#popclip
name: GoToFileSearch
interpreter: /bin/zsh
icon: square GTF
shell script: /usr/local/bin/gtfs --project --query=$POPCLIP_TEXT

But on every execution I see the above mentioned spinner for annoying 3 or more seconds. Why is this? No Apple Script involved, PopClip does not need to wait for any response by anything but simply send a command to zsh.

What am I possible doing wrong here?
I change my initial approach of simply giving zsh as interpreter and gtfs as executable by using the respective full paths (I created a symbolic link in /usr/local/bin to the executable residing in GTF’s application bundle for ease of use). No change. Same if I use the direct path into the package (/Applications/GoToFile.app/Contents/Resources/bin/gtfs).

Thanks a lot for any pointers,

Peter

1 Like
2

Meanwhile I tried to use other shells like

/bin/sh

because I suspected the issue might be related to the loading time of the shell.
While /bin/sh starts up instantaneously, the issue remains unresolved.

3

PopClip will patiently wait for the zsh process to complete even if it’s not returning any data.

Is gtfs running for those 3 seconds? Since we don’t need to wait for a response, try running the gtfs command in the background by adding a & at the end of your shell script command:

#popclip
name: GoToFileSearch
interpreter: /bin/zsh
icon: square GTF
shell script: /usr/local/bin/gtfs --project --query=$POPCLIP_TEXT &
4

Nick,

thanks for your quick response.
No, gtfs is not running for 3 seconds. To me it seems that the spinning ends when gtfs is finally called.

If I run

/usr/local/bin/gtfs --project --query=XXX &

in the terminal, GoToFile responds instantaneously and the shell returns in a fraction of the time, too.

/usr/local/bin/gtfs --project --query=XXX

is even faster for both GoToFile and the terminal shell.

So this seems to be a PopClip issue, IMHO.

Thank you - for this (otherwise) great utility.

Peter

5

I’m unable to reproduce this issue myself so let’s dig in further to your setup.

Is it possible you have anything in .zprofile, .zlogin or .zshenv that is taking a few seconds to execute?

Also could you please confirm which version number of PopClip you are using?

6

Yes, but I also tried with /bin/sh with same result.

Also could you please confirm which version number of PopClip you are using?

4688 - the most recent, AFAIK.

7

Sorry for placing this message here:

I am trying to post in this thread, too:

https://forum.popclip.app/t/extension-for-gotofile/3332

But I am always getting the cryptic (bogus) error:

An error occurred: You’re replying a bit too quickly. Please wait 4 minutes before trying again.

Too quickly, for what. 4 minutes have passed long ago and several times on top of it. It always comes up with this error…
I am afraid I find this very annoying - now got this error again for trying to post in this thread. This time it complains about being 53 seconds to early…
So the post is somehow on topic, now.

8

PopClip runs scripts within a non-interactive login shell instance of your default shell.

So even if you specify sh as the interpreter the PopClip extension config, it will still call an instance of zsh (assuming zsh is your system default shell) first. PopClip will run this command:

/bin/zsh -lc '/bin/sh'

…and pipe the script contents into that.

Any zsh startup scripts that would be run by a default zsh login shell will therefore be run on each invocation by PopClip.

(The reason it’s ‘wrapped’ in a default shell call like this is to ensure it has access to your path and other login shell variables that your scripts might need.)

9

I see. Makes sense.
But what can I do to achieve better performance?
I would mind changing my zsh setup only to please PopClip :grinning:

10

Do consider whether you actually need need your startup scripts for all login shells, or only for interactive shells — in which case you could move them to .zshrc.

Failing that there’s a PopClip hidden setting:

defaults write com.pilotmoon.popclip NoLoginShell -bool YES

which will call the wrapper shell for all extensions with -c instead of -lc. Thus it won’t run .zprofile or .zlogin, but will still run .zshenv.

11

This works perfectly (but of course might have its drawbacks otherwise): GTF responds within a split of a second.

Any chance to make this settable by extension?
E. g. by setting the interpreter to zsh-c or something?

This would be the easiest fix for lazy me :grinning:

Not yet tried the other options, but I remember vividly the horrible amount of experimentation with various zsh configuration files to finally come up with a config that works for me and which I am therefore reluctant to change…

Thanks,

Peter

12

Nick,

following your advice I moved almost everything from .zprofile to .zshrc and set PopClip’s hidden setting back to

defaults write com.pilotmoon.popclip NoLoginShell -bool NO

Seems to work for the moment, PopClip’s start-up time being a lot faster than before - unsurprisingly now, thanks to your explanation.

I just hope that I won’t hit unwelcome side effects in other areas due to this change. Will have to see.

Thanks a lot!

Peter

13

Ah, good. I think most of the stuff that people have in startup scripts, like oh-my-zsh and such things, tend only to be needed for interactive shells, so you should be OK. Let me know if you run into any trouble. I’m certainly open to tweaking things if there is a demonstrable need.

14

OK - great! Thanks!