Am trying to make a base recursive handler to choose directories to perform actions on, and this code I found online seems to work, but gets stopped straight away whenever a file contains a special character.
I get the old "Can’t make “…” into type string. error.
Now if I drag the file into Terminal, it handles it fine after converting into Unicode. How do I do that with each alias that Finder locates?
createList(choose folder)
on createList(item_list)
set the the_items to list folder item_list without invisibles
set item_list to (item_list as Unicode text) as string
repeat with the_item in the_items
set the_item_alias to (item_list & the_item) as alias
if folder of (info for the_item_alias) then
my createList(the_item_alias)
else
-- Execution Code
end if
end repeat
end createList
createList(choose folder)
on createList(item_list)
set the the_items to list folder item_list without invisibles
set item_list to (item_list as Unicode text) as string
repeat with the_item in the_items
set the_item_alias to (item_list & the_item) as alias
if folder of (info for the_item_alias) then
my createList(the_item_alias)
else
log the_item_alias
end if
end repeat
end createList
If that runs OK, the problem is somewhere in your other code.
Nope it doesn’t. I get Can’t make alias “…” into type string.
But if I use:
set theFile to POSIX path of (choose file)
it can parse the link, but then I can’t use Finder any further. POSIX handles the non-ASCII characters fine, but then you are stuck in shell-script land, which I might have to do, but everything else runs great in my existing handler, accept when I run into a nonASCII file name.
P.S. an example is one file that has the word L̶i̶t̶t̶l̶e̶ in it. Choose just can’t deal with it. When I pull it over to Terminal via drag I get: L\314\266i\314\266t\314\266t\314\266l\314\266e\314\266 as the POSIX representation of the word.
Just be aware that find doesn’t distinguish between folders and packages. Depending on what you’re searching for/in, that may or may not make a difference.
It can tell files from directories, but it knows nothing about packages, which are directories that look like files – it treats them both as if they were folders. Things like apps, .rtfd files, .scptd files, and others. These are things that exist above the Unix level that find operates in.
you can also do ! -path \( ‘/System/’ ‘/Library/’ \) and anything else you want ignored.
VERY fast too.
Have learned anytime Finder gets to be a pain to look to shell-scripts and the Linux folks have never let me down. As Mac people, it often feels like we’re really missing out by not getting more acquainted with Bash.
Great. But you’ve just made my point: find doesn’t understand packages, so you need to modify your search to try to eliminate them. That’s what I was getting at in the first place.
Fine. But we need to understand that macOS is built on top of Unix, so we need to allow for the fact that Unix tools don’t know what happens at that higher level. Packages are one of those things. I’ve known people to corrupt applications simply because they didn’t allow for the fact that some Unix tool would treat them as directories. (And yes, one of those people was me.)
OK you’ve lost me now. How do you think Finder does it? I can promise you it isn’t some self-awareness of of app-bundles, but is most likely just a path filter. In the old days with File-Forks it was as close as it was ever going to get to what you are alluding to. The point is anytime you can NOT use Finder it’s good because of its bloat, slowness and lack of priority (niceness). Shell scripting is more effective in every way. Just put this to the ultimate test and it bypassed all Libraries (main, system and ~/Library), /Private, /usr, /bin, /sbin, /Volumes, and Caches and only touched User Docs. Not bad for ONE LINE OF CODE.