Can someone explain this invisible applescript result?

Scripting Forums AppleScript | Mac OS X
#1

(disclaimer: I tried 1st to post this in the Unscripted forum but the “Post new topic” button was not to be found at the top of the page. :/)

While testing a pair of scripts I ran into something unfamiliar; an invisible item in an apparently empty list!
1. My ‘Applescript.app’ uses ‘run script’ to call my ‘beep.scpt’ into action.
2. ‘beep.scpt’ is nothing more than the word ‘beep’, so it does that nicely.
3. ‘Applescript.app’ receives no result from ‘beep.scpt’ (because there was nothing to return).
4. Since ‘Applescript.app’ also calls other scripts which (unlike ‘beep.scpt’)
may return something, it uses this sloppy trick* to catch any non-result…

 set rslts to {} & (run script posixPathToOtherScript)--some return some do not.

  ...
  5. What I see ''returned'' in Script Editor (Version 2.9 (191), AppleScript 2.5)  is 
      either  [1.] an empty set of brackets ( {} from 'beep.scpt' ) 
            or  [2.] properly bracketed text or numbers from other scripts.
  6. But, when I ask for the count of the empty list from 'beep.scpt', 
      it mysteriously claims [b]the empty set has 1 item![/b]
  7. A display dialog test of item 1 of the empty bracket revealed that 
      this invisible item's class is "capp". However, the following tests return more mystery...

 set rslts to {} & (run script posixPathToOtherScript) ---
           say (count of rslts)--says 1
	   say rslts is {}--says  false
	   say (class of item 1 of rslts) as text is "capp"--says  false
	   display dialog class of (item 1 of rslts)--displays "capp"
	   say (item 1 of rslts)-- err "Can’t make current application into type text."
	   return properties of item 1 of (rslts as list)--err "Can’t get properties."  

    Can anyone shed some light on this one? What is class "capp"?...
    Thanks in advance.

    [i]*Yes, I could trap it some other way.[/i]

Model: Mac Pro
AppleScript: 2.9
Browser: Safari 602.1.50
Operating System: macOS 10.14

#2

Hi. I speculate that a remote run call implies (run script (load script)), and it appears that load script’s value is being returned, which is an application.

#3

Interesting. That would match the result of another test which indicated “capp” is ‘application’…

set rslts to  ({} & (run script scptPTH)) as list

	return {rslts, ¬
		("" & rslts), ¬
		(every item of rslts), ¬
		(class of item 1 of rslts), ¬
		(count of every item of rslts), ¬
		(a reference to item 1 of rslts)} ----->{{}, "", {}, application, 1, item 1 of {}}
#4

OK, I tried replacing the called script’s simple “beep” with this…

  on run input
  	return properties of input
end

Which returned a nice confirmation of your idea Marc Anthony…

 [i]Result of calling "beep.scpt" from "Applescript.app"..[/i]

{class:application, selection:insertion point after character 1565 of text of document "Applescript.app", frontmost:true, name:"Script Editor", version:"2.9"}}

…
Result of running “beep.scpt” in Script Editor…

{selection:characters 1 thru 72 of document "beep.scpt", frontmost:true, class:application, name:"Script Editor", version:"2.9"}
#5

It seems the “application” invisibly residing in my empty brackets may actually be the Script Editor or whatever process is doing the work at the time…
Note the phrase “current application”.

error "Can’t make current application into type string." number -1700 from current application to string

Running Applescript.app as an independent app seems to not like the aforementioned “sloppy trick*”. It gives this error…

error "Can’t make current application into type string." number -1700 from current application to string

Attempting to force the dialog that revealed the class “capp” to intentionally put “capp” into it’s title actually caused Script Editor to automatically-coerce my code by erasing parts of it, then fail with “Script Error: AppleEvent handler failed.” …


try
     set rslts to ({} & (run script scptPTH))
on error err
        #display dialog err with title "" &  current application's class <--original code test
        #display dialog err with title "" & class of current application <--original code test
         display dialog err with title "" & class             <--code auto-coerced at compile.
end try

So, it seems any untidy reference to abstract voids in the code are magically presumed to be the “first person being addressed”, i.e “current application”. But attempts to have it identify itself as such scare it off to the shadows. The following obvious-ruse revealed it in all three modes; in-editor-run, called-from-editor, & called-from-app…

on run input
	return say --''current application'' automatically fills in here where text should be. 
end run
#6

I was used to handling awkward results such as “undefined”, or “missing value”, but this was a real ghost in the machine! Calling scripts who don’t have anything to offer, or whose output is unexpected is not recommended.

Here’s my testing handler for now. Any better ideas are appreciated.
Maybe it’ll help someone dig into their problem.
Included is its nemesis, for causing intentional testing errors…

save as “Applescript.app”


set scptPTH to POSIX path of (path to desktop) & "beep.scpt"
set tst to "#  	err  	rslt     		typ    	cmnt" & return
repeat with n from 1 to 10
	set {x, y, z, abc} to testFailedCallsHandler(scptPTH)
	set tst to tst & n & ". 	" & x & "   	" & (text 1 thru 12 of ("" & y & "            ")) & "   	" & class of z & "   	" & abc & "   	" & return
end repeat
return tst
on testFailedCallsHandler(scptPTH)
	try
		set errNUM to 0
		set err to "none"
		set rslt to "none"
		set cls to "none"
		set rslt to ({} & (run script scptPTH)) as list
		set cls to class of (item 1 of rslt)
		if cls is application then set {rslt, errNUM} to {"no result", 1} --"got beeped or similar" ---> handles: ''beep'', ''beep 2'', ''return beep'', possibly others?
		if rslt is {missing value} then set {rslt, errNUM} to {"no result", 2} --"missing value"
		if rslt is "An error has occurred." then set {rslt, errNUM} to {"error", 3}
		if rslt is {null} then set {rslt, errNUM} to {"no result", 4} --"null"
	on error err
		if (err begins with "The variable ") and (err ends with " is not defined.") then set {rslt, errNUM} to {text (13) thru (-16) of err, 5} --"The variable undefined is not defined."
		if err is "No result was returned from some part of this expression." then set {rslt, errNUM} to {"no result", 6} --{} ---> handles: ''say'', possibly others?
		if err is "Can’t make current application into type text." then set {rslt, errNUM} to {"no result", 7}
		#return {911, err}
	end try
	return {errNUM, cls, rslt, err}
end testFailedCallsHandler

save as “beep.scpt” to your desktop…

on run input
	return run script some item of {er1, er2, er3, er4, er5, er6, er7, er8, er9, er10, er11, er12, er13, er14, er15, er16, er17, er18, er19, er20, er21, er22}
end run

on er1()
	beep
end er1
on er2()
	beep 2
end er2
on er3()
	run (beep)
end er3
on er4()
	run {beep}
end er4
on er5()
	return beep
end er5
on er6()
	say
end er6
on er7()
	return say
end er7
on er8()
	say (run me)
end er8
on er9()
	run script "say"
end er9
on er10()
	return item pi of {}
end er10
on er11()
	stop
end er11
on er12()
	missing value
end er12
on er13()
	null
end er13
on er14()
	{}
end er14
on er15()
	0
end er15
on er16()
	me
end er16
on er17()
	properties of me
end er17
on er18()
	machine
end er18
on er19()
	""
end er19
on er20()
	path to me
end er20
on er21()
	startup disk
end er21
on er22()
	name of me
end er22
#7

No, it is the current application (“capp”, application which takes control when other script doesn’t return nothing). You can check this using the following script. And what result you expect from beep, which doesn’t return nothing?


script o
	beep
	-- return 0
end script

set rslts to {} & (run script o)

a reference to class of item 1 of rslts --> class of item 1 of {current application}
-- display dialog (get name of current application)

Uncomment return 0 to see that all are returned as expected.

SIMPLER TEST:


{} & (beep)

a reference to class of  result --> class of {current application}
--display dialog (get name of current application)

So. As I see, the result of {} & (beep) is {current application}. I think, Apple could have implemented the return of this result in such cases, but either was too lazy or did not see anything valuable in it.

#8

When you run this:

{} & ([something that returns no result])

in Script Debugger, you can see more what’s going on. If you set the result to AEPrint, you will see:

[ null() ]

In other words, AppleScript has added a null descriptor (a descriptor with no parameter or attribute values set).

In Best view, it appears as:

{current application}

That’s presumably because a null descriptor has no specifier form, as it’s not meant to appear, so it returns its parent specifier.

You could argue it’s a bug that the result is not simply an empty list. But it’s easy enough to trap for:

set x to ([something that returns no result])
try
	x -- will have no value
end try