Startup screen shows first time


(Ray Robertson) #1

Sierra, High Sierra, Mojave. I’ve run in to many situations attempting to share scripts with clients in recent macOS versions. I won’t go into that now. But using shared Dropbox folders seems to work around many problems. Except one, which is failing consistently with two High Sierra systems.

I update a script applet via Dropbox, making sure to have Show Startup Screen unchecked. It runs fine on my system. But on another Mac, the first time it is launched—via another script calling it—the startup screen shows up. After that, the startup screen never shows up again. It happens with most applets on this system, but not all. Still consistent enough, though.

Has anyone else seen this, or does anyone have a suggestion for modifying the bundle contents or some other workaround to try to the prevent this? TIA.


(Shane Stanley) #2

Are you zipping them before sharing them on Dropbox?


(Ray Robertson) #3

Not in this case. And in general for some clients zipping just seems to lead to problems now. Sometimes the disk image approach does help, but not always. But this issue is just with two computers sharing the same folders and the remote computer runs the scripts from there.

The only other thing I can think of is the master script is running the child scripts in a subfolder at the same level. Although in general Dropbox seems to avoid the security issues with “unblessed” folders, I wonder if this is another security thing. Still, it is strange that it only happens on the first run.


(Shane Stanley) #4

My first guess would be that Dropbox is having some kind of issue copying the file that stores this setting, applet.resrc or droplet.rsrc.


(Mark Alldritt) #5

I’ll add that I’ve head many complaints about DropBox failing to handle updates to the contents of bundles properly.


(Ray Robertson) #6

I appreciate the suggestions. I have not been able to see any differences in applet.rsrc or droplet.rsrc. I know Dropbox is suspect—but it is a fact of life, especially in the corporate world. Deservedly so IMO compared to Apple’s implementations.

What I have seen but can’t always replicate:

  1. I have a script .app file on dropbox
  2. I turn off dropbox syncing
  3. I open the applet, switch to debugging mode, set a breakpoint to stop it before it calls another script
  4. I close the original applet without saving
  5. I turn on droplet syncing. The applet mod date shows as unmodified, but dropbox shows me it is updating syncing on the applet.

I can’t replicate this reliably, though. Before I try to further, can you let me know if it possible that simply turning debugging on and off somehow modifies the contents of the bundle to the point where Dropbox sees the need for a re-sync?


(Mark Alldritt) #7

I just looked through the code, and Script Debugger looks for the stayOpen and showStartup settings in the applet.rsrc or droplet.rsrc file, depending on the kind of applet being opened. The values of these settings are written using Apple’s OSACreateFile call which creates the entire applet bundle.

Enhanced applets store the stayOpen and showStartup settings in the Info.plist file.


(Shane Stanley) #8

The recompile done as part of turning debugging on probably triggers an autosave, and that might come into play somehow.


(Ray Robertson) #9

I’ll bet it is something like that. I saw it again today—I open a script in SD with Dropbox syncing off, switch to debug mode, then close the script app without saving changes. When I turn Dropbox syncing back on, it triggers a resync of the bundle.

I wonder if Dropbox does some type of “pre-indexing” watching/searching before syncing is turned back on, detecting the bundle as modified in its Debugging state, and then not realizing later that it was closed without saving changes. Just a wild guess—but it sure is strange to see something with the same modification date updating/resyncing.