Do High Sierra and Mojave pass variables between scripts differently ?

I have an applet which calls a script [the first script] within its resources folder in background using do shell script. So, the main script continues and has no further involvement. The do shell script command passes a number of parameters including the full path and name of a file.

The first script also calls a script [the second script] within the same resources folder in background using do shell script. It picks up the path and name of the file passed from the first script and checks its contents etc. If it finds certain data in the file it kills the process of the first script.

This all works fine in High Sierra. However, it does not in Mojave. In Mojave, the name of the file is stripped off the variable that is passed by the first script ie. that variable when used in the second script has just the path. Here is an example:

Variable value passed from the first script:

Variable value received by the second script (as shown by a “display dialog” immediately after a “on run”):

Why would the variable value be truncated by a script in Mojave but not in High Sierra ? I’ve tested in Catalina and found the same problem. I’ve noticed that the quotes sent by the first script are stripped off the variable value in the second. That happens in High Sierra too but doesn’t affect the operation of the second script. The applet has been granted required permissions in Mojave although, in this case I don’t think that would be an issue.

Thanks.

How to put this… I find it a bit hard to believe at face value. I mean, haven’t you been doing this for some time? And your script has been working fine in Mojave.

Fair enough. Both my Macs run High Sierra and that’s what I’ve been testing on. This has never been a problem in High Sierra. The symptom in Mojave is the lack of a dialog that should pop up when the second script reports the content of the file. Because it’s not getting the file name, the second script stops running.

For a while now I’ve had a local Apple club 2008 MacBook laptop which I patched to run Mojave. I noticed that the second script wasn’t behaving normally in Mojave but didn’t think much of it. On Tuesday, I patched the laptop to run Catalina (beta). I tested a few applications to see what worked and what didn’t etc. Naturally, 32-bit applications don’t run. I found that my applet worked except for this issue.

I didn’t mention before that I’m using osascript in the do shell script call like this:

I’ve just found that the osascript executables in HS and Mojave are different. In High Sierra it is 43136 bytes. But in Catalina, it’s 56528 bytes. There could be lots of reasons for changes but, I wonder if it’s relevant.

Anyway, I’ll re-do all the testing in both High Sierra and Mojave and make sure my marbles are all intact. Maybe the OS patching is contributing to strange behaviour. I’ll look for an Apple club member who is running a Mojave supported Mac to help test.

Many thanks.

There could be a security issue with unsigned code. I tried to uncomment one of the dialogs in archive, and I saw neither the dialog or the download. It’s possible the OS recognized that the code-signing was no longer valid.

OK, most of my marbles are back where they belong. Of course Mojave and High Sierra pass variables in the same way. It’s my code that’s the problem particularly, dealing with POSIX and non-POSIX path names. A POSIX path name can look like this: “/Users/chris/Documents/resume.doc”. A non-POSIX path name can look like this: “Macintosh HD:Users:chris:Documents:resume.doc”.

My code was working with a non-POSIX path and I forgot that such paths include the hard drive name which can have a space (the path was to a location in Applications which I thought was OK). They thus must be surrounded by quotes when being passed to a do shell script. I had no quotes and so the path was not passed properly.

Luckily there were no abnormal permissions issues. I’ve had no trouble running both signed and unsigned copies of the applet.

Many thanks to Shane for your patience. Cheers.

Can someone explain the use of the do shell script "osascript… structure?

Is not it equivalent to script itself execution? After all, “forward-backward-forward” is equivalent to “forward”. Only with excessive body movements. Or, am I wrong?

Using osascript runs a script in a process of its own.

Thanks, Shane, for the reply. So… there is much more that I can learn from… :rolleyes:

In my case, it enables a script to be executed in background while the calling script continues. The line of code looks like this:

set pid_2nd_script to do shell script "osascript -s s " & location_2nd_script & " " & params_2nd_script & " " & " > /dev/null 2> /dev/null & echo $!"

The process ID is returned so the first script can kill the 2nd script. I got all the good ideas from a post here on MacScripter: [topic]34563[/topic]