shell.openPath() and URI encoding

Photoshop
1

Hi,
it seems like shell.openPath() doesn’t like the path string to be encodeURI()-ed in advance on a Mac.
When the path contains a space, it translates (as expected) to %20, but openPath()doesn’t like it and it fails to find/open the asset. If the path has no spaces, it works either with or without encodeURI()—as I’d expect.

To sum up:

// On a Mac
shell.openPath(encodeURI(somePathWithSpaces)); // FAILS ?
shell.openPath(somePathWithSpaces); // OK

// On Windows
shell.openPath(encodeURI(somePathWithSpaces)); // OK!
shell.openPath(somePathWithSpaces); // OK

Correcting for platform (escape chars, forward vs. backward slashes, etc), it seems like spaces in the paths are not an issue on Windows, as my friend @svumme told me after performing a bunch of tests.

Could you please confirm that this is the expected behaviour, and we should basically never use encodeURI() to be sure everything works on both platforms?

Thank you!!

—Davide

1 Like
2

Basically:

api Parameter type use encodeURI?
openPath string<path> Never—this goes through OS process launch APIs
openExternal string<url> Always
1 Like
3

Thanks Kerri!!
In fact I migrated to openPath from an openExternal hack, and kept encodeURI—I’m going to get rid of it immediately!

4

Somewhat related - URI encoded or not it seems from my tests that openExternal doesn’t work with local paths. I get that this behaviour tracks with UXP’s token permissions system, but it also seems to apply to filepaths within the plugin folder.
Is that intended behaviour?

Use case: opening an HTML instruction manual from the flyout menu.

5

The way this behavior is handled depends on what version of the UXP manifest you’re using. Are you using v5? If so, you have to explicitly declare the launchProcess permission in order to use openExternal.

1 Like