I’m looking to enable my users here to select a folder or file on our file server ( Ventura SMB ), generate and then share some form of functional text that when clicked by the recipient can open the selected folder or the selected file’s container. I can find no method of doing this.
In lieu of this, I can take the selection and generate an AppleScript app using OSACompile that contains a shell script that opens the target. Of course a lot of tools currently used for inter-office communication won’t transfer the resulting AppleScript. I’m looking at you Teams!
Does anyone here know of any method of generating any functional link or other data/app/etc that can be shared with other users that will reveal a location on a mounted macOS file server?
Is your difficulty arising specifically with generating links for a file resource on a mounted/remote volume (which would imply you are able to accomplish this for a file located on your boot drive) ? Or is the fact that it’s a mounted volume not relevant to the problem, and it’s about generating clickable links to file resources generally ?
That’s a good question, @CJK.
But, @paulskinner, if you don’t need to worry about the “network volume not mounted” situation, you could give everyone a little AppleScript that takes the file currently selected in the frontmost Finder window and makes a “file” URL for it. Actually, this sample code takes the selected files (might be more than one) and makes a return-delimited list of “file” links. When a user clicks one of these links (and has the necessary volume mounted), the Finder should open the enclosing folder and highlight the file/folder specified by the link. If you want this to ALWAYS return a single link for whichever file is the 1st in the selection, you could add as “exit repeat” line before the “end repeat” line to only get a single link into the clipboard. But, it might not be clear which selected file/folder will be “1st”, so the code behavior below of getting them all is probably best.
tell application "Finder"
-- get the selected files/folders:
set selectedItems to selection
-- convert to an AppleScript list of file links:
set fileLinks to {}
repeat with oneItem in selectedItems
set oneFileAlias to oneItem as alias
set oneFileLink to "file://" & POSIX path of oneFileAlias
set end of fileLinks to oneFileLink
end repeat
end tell
-- save delimiters, then convert list of links to return-delimited text:
set {oldDelims, AppleScript's text item delimiters} to {AppleScript's text item delimiters, return}
set fileLinks to fileLinks as text
-- restore delimiters:
set AppleScript's text item delimiters to oldDelims
-- put the list into the user's clipboard:
set the clipboard to fileLinks
return fileLinks
Note: There could be a potential wrinkle where it looks like the volume is “WhateverMyNetDriveIs” in the Finder, but behind the scenes it is mounted at this POSIX path: “/Volumes/WhateverMyNetDriveIs 2” (or 3, or 4, or so on).
If that happens, then users are accessing the same network drive, but the file links they share with each other will fail, since their paths are different. Hopefully your network isn’t having that issue. I think it is related to some Bonjour flakiness.
File URLs are functional, ish, but I have to percent encode them to handle any spaces in the path.
In Outlook.app, clicking these File urls generate a “Grant File Access” dialog. Clicking its “Select” button brings up a sheet which offers a “Grant Access” button. Once for each unique link. :[ Not fun, but not horrible.
Teams styles them as links, and you can choose “Open link…” Nothing happens, but you can choose it. Same with Messages.app. meh!
I currently generate posix path(s) as return delimited text for the users to share. These are at least manually locatable, or they can be pasted in to the “Go/Go To Folder…” menu to reveal the target.
In a past OS the contextual menu offered “Reveal In Finder…” when an posix path was selected. Not so in Ventura. I suppose coding myself a new contextual path-revealer might be a good option. Maybe make it support HFS, Posix and file://
open as a command (aka program) is not part of the POSIX specification. It is only available on macOS. Not in any other Unix variant. Which makes it, in my book, a macOS command. The shell is completely irrelevant in this context, btw.
I’m not sure if t was a template or standard service. But I have a Finder service when right click on a finder item. The service is called “Copy Path”,
Let me investigate the workflow and get back to you. It could easily be adapted to create a NSAttibutedString
➊ You can coerce the selection to an alias list to save doing it one-by-one:
set selectedItems to the selection aa alias list
➋ Did you know that both Finder and System Events can return a file URL for a file or folder on the disk ? As @paulskinner noted, a file URL typically needs to be percent-encoded, but Finder and System Events do this for us:
set oneFileLink to the URL of oneFileAlias
which will yield a string similar to: "file:///Users/CK/Documents/A%20Text%20File.txt".
Both of these will improve performance, though the percent encoding is clearly the biggest advantage:
tell application id "com.apple.finder"
set fs to the selection as alias list
tell a reference to fs to repeat with f in it
tell f to set the contents to the URL
end repeat
end tell
set my text item delimiters to linefeed
set the clipboard to fs as text
@paulskinner didn’t ever make it clear whether the issue was purely around generating file links, or obtaining an appropriate file path to a network resource. For the latter, the NSURLResourceKey item called "NSURLVolumeURLForRemountingKey" will provide the actual e.g. smb:// file URL (from which you can retrieve its absoluteString())…
That is true. But the term “Unix command” refers to the core set of commands that come shipped with all Unix installations. These will run on all Unix systems by virtue of their adhereence to the POSIX standard. @chrillek is correct in saying that open is not a Unix command, both in the sense that it is not in the list of The Unix Commands, and also in that it’s specific to BSD systems (it was initially written for and appeared in NeXTSTEP). Commands like open wont necessarily adhere to the POSIX standard (I dont know off the top of my head whether it does or not), so wont work on other systems without adapting in some way, or it may do but with different results (e.g. killall).
Honestly, there might be enough going on here that it could be worth you building yourself an AppleScript applet (or a pair of them).
You could essentially make your own custom URL format that covers your needs, but preface it with a custom URL protocol. Perhaps almost the same as the “file:” protocol, but “filexyz:”, where xyzzy is your organization’s acronym… Then, have your AppleScript applet register as the owner of that custom protocol. Not all apps will automatically format that as a link, so folks would have to copy it, but then you could have the “Open Link” AppleScript stay-open applet automatically check the clipboard when it is activated. It then converts the filexyz link into a normal file link, and people would only have to Grant Access the first time they use the applet (or a new version of it).
The “Create Link” applet could use what @CJK suggested, but then change the “file:” at the beginning to your “filexyz” equivalent.
Someone did something similar using AppleScript back in 2005: OS X URL handler to open links to local files - I think a few things have changed since then, but the general idea is the same. To set the CFBundleURLSchemes in the Info.plist, follow the instructions at CFBundleURLSchemes, since the 2005 post’s links about that have gone 404.
Making your own applet that handles a custom URL protocol can take a bit of work, but then you have a lot more control over how it works.