Problem with testing a folder

Hi all

Got some script to test if a file or folder exist and want it to work with a path with / or :

exists POSIX file

Or

exists file

When I want to test a folder

exists folder

But this will not work

exists POSIX folder

If I use exists POSIX file for a folder it also seems to work but love to know the correct way

Hey Ron,

Here’s my general purpose handler for that:

---------------------------------------------------------------------------------
--» exTant()
---------------------------------------------------------------------------------
--  Task: Determine whether a file or folder exists.
--  dMod: 2015/06/30 07:12
---------------------------------------------------------------------------------
on exTant(_path) # Takes an HFS, Posix, or ~/Posix path as input.
	try
		
		if _path is "~" or _path is "~/" then
			set _path to (POSIX path of (path to home folder as text))
			
		else if _path starts with "~/" then
			set _path to (POSIX path of (path to home folder as text)) & text 3 thru -1 of _path
			
		end if
		
		if _path starts with "/" then
			alias POSIX file _path
			
		else
			alias _path
			
		end if
		
		return true
		
	on error
		return false
		
	end try
end exTant
---------------------------------------------------------------------------------

[ Edited to repair the glaring bug Shane pointed out and to cover instances of home-notation without a following path: ‘~’ & ‘~/’ -ccs ]

That might be better as a simple else. Otherwise:

exTant("Volume that doesn't exist")
--> true

I’ll reply to your mail here Ron:

The most easiest way without having to worry about the path is using system events:

tell application "System Events" to return exists disk item thePath

to support furl and file specifiers you extend the command to an explicit to string coercion:

tell application "System Events" to return exists disk item (thePath as string)

The path can now be an furl, file specifier, alias, UFS/POSIX path string or HFS path string.

Thanks all for helping me with examples

Used the script from DJ for Excel 2011 and because the new Mac Office version have problems with running applescript with the VBA MacScript function I can’t use it in this version. But they fixed VBA Dir (no filename limit of 32 characters anymore) so I can use that in the Office beta.

See this start page that I publish today for VBA users
http://www.rondebruin.nl/mac/mac008.htm

Thanks

Yeow!

Thanks Shane. I’ll fix it in the original post.

That’s pretty comprehensive, but unfortunately it doesn’t support System Events’ own item specifiers (which won’t coerce to text).

If an app’s specifiers are involved, by definition nothing but that app can resolve them. That’s really just the nature of the beast.

Hey Shane,

Not precisely true.

tell application "Finder"
	set finderRef to first item of (path to documents folder)
end tell
--> folder "Access_Aliases" of folder "Documents" of folder "chris" of folder "Users" of startup disk of application "Finder"

set myPath to finderRef as text
--> "Ryoko:Users:chris:Documents:Access_Aliases:"

0n OSX 10.9.5.

Funny details.

If you look at the events log, Christopher’s last code give:

tell application "Finder"
	path to documents folder
	get item 1 of alias "SSD 500:Users:<user Account>:Documents:"
	get document file ".DS_Store" of folder "Documents" of folder "<user Account>" of folder "Users" of startup disk
end tell
Résultat :
"SSD 500:Users:<user Account>:Documents:.DS_Store"

Yes, it appears that :
(1) the script extracts item 1 of what, as far as I know, is not a list
(2) it convert the alias which is known by quite every applications into a reference which quite only the Finder is aware of.

Yvan KOENIG (VALLAURIS, France) mercredi 1 juillet 2015 18:33:13

Hey Yvan,

Thanks for pointing this out.

SCRIPT:

set docsFolder to path to documents folder

tell application "Finder"
	set finderRef to first item of docsFolder
end tell

tell application "BBEdit"
	set myPath to finderRef as text
end tell

EVENT LOG:

tell current application
	path to documents folder
		--> alias "Ryoko:Users:chris:Documents:"
end tell
tell application "Finder"
	get item 1 of alias "Ryoko:Users:chris:Documents:"
		--> folder "Access_Aliases" of folder "Documents" of folder "chris" of folder "Users" of startup disk
	get folder "Access_Aliases" of folder "Documents" of folder "chris" of folder "Users" of startup disk
		--> "Ryoko:Users:chris:Documents:Access_Aliases:"
end tell
Result:
"Ryoko:Users:chris:Documents:Access_Aliases:"

This is on OSX 10.9.5.

Very interesting that the Finder-Ref coerced to Text within a BBEdit Tell-Block reaches back to the Finder.

And if the Finder can do this then why not System Events?

It is unsurprising that the Finder can resolve an alias, so I’ve separated that out in the script.

You can refer to items by their index in the Finder, so that is of no surprise:

tell application "Finder"
	set iLoc to (insertion location)
	set item_01 to item 1 of iLoc
	set item_02 to item 2 of iLoc
	set item_20 to item 20 of iLoc
	set item_40 to item 40 of iLoc
end tell

So the two things I see as “funny” or of especial interest are:

A) Where the coercion to text takes place (Finder).

B) And I think it’s very surprising for you to end up with a .DS_Store file as a result.

I thought I posted this the other day, but whatever…

If you run this:

tell application "Finder"
   set finderRef to first item of docsFolder
end tell

and look at the result rather than the log, you see it ends in of application “Finder”. So coercing it inside a BBEdit tell block is a bit like a tell within a tell.

FWIW, I get the same here – it depends on whether you have hidden files visible or not.

Hey Shane,

I KNOW that finderRef is a Finder Reference ” I set it to one and named the variable appropriately for a reason.

The interesting thing is that coercing it to text OUTSIDE of a Finder-Tell works ” whether in another application Tell-Block or in vanilla AppleScript space.

If you try this with System Events it will throw an error.

If try it with other Application-References it will throw an error.

The fact that this coercion creates its own invisible tell-block is anomalous.

Ah, that makes sense. Do you run your system that way normally? If so ” just out of curiosity ” do you have any special reasons?

I (almost) never turn invisibles on in the Finder. If I want to see them I fire up ForkLift or Path Finder and make them visible.

But it will throw an error inside a System Events tell block, too – you can’t coerce SE file references to text.

Here’s a different example of the same thing happening:

tell application id "com.barebones.bbedit" -- BBEdit.app
	set x to document 1
end tell

tell application "Finder"
	name of x
end tell

Yes, I do. It’s no big deal, but I like to see exactly what’s where.

Hey Shane,

Oh, well that’s true.

Huh. That’s wild. I’ve never noticed that before.

AppleScript is routing the event to the correct application? That seems to fly in the face of the convention of not using osax-calls within an application tell-block.

So you’re a control-freak?

Well it’s that or throw an error. It’s always been that way.

More like I changed it once, and never bothered changing it back…