On Fri, 2022-01-07 at 19:57 +0100, Christof Ressi wrote:
When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch.
Actually, it's resolved to the current working directy. This is expected behavior.
Expected by whom? Not by a regular user, I suppose, since virtually all other objects interfacing with IO interpret relative paths as relative to the patch for _writing_. It's only [file] that stands out and behaves differently and its the only one that cannot write a file relative to its patch. If you say this behavior is intended, then I fail to see the usefulness of this design choice.
Consider this case (a real problem I currently face, not something made up):
I am writing a patch with a configurable path for writing binary blobs. The default in the configuration is set 'myblobs' and myblobs is a directory that exists near the patch. The idea is that new binblobs are saved there. Since [file] won't find 'myblobs/newblob.dat' near the patch, I can use [dir(-[pdcontrol] to find the patch's directory and append the configured path to it: '/path/to/my/patch/myblobs'. Now, I am able to write my new binblob to the configured path at '/path/to/my/patch/myblobs/newblob.dat'. Now, the user configures a custom absolute path for their binblobs: '/opt/myblobs'. My patch appends this to the patch's path: '/path/to/my/patch/opt/myblobs' and boom, that is not what the user has expected. I only need to append the configured path to the patch's path if the configured path is a relative path. But how can I reliably detect that? Not that easy as I explained in the other mail.
What I think should happen when instantiating any [file] objects is to set the working directory to the patch's directory and not to Pd's start directory. The latter is irrelevant in the cases I can think of.
The [file] interface itself is just a thin wrapper over the POSIX file API and therefore agnostic of Pd's search paths.
Absolutely. I don't see how I am challenging that. I think the decision of what the current working directory is is wrong.
As Antoine has already mentioned, use [file which] if you want to resolve a relative path to the canvas environment.
Yeah, this works fine for finding already existing files, but as the help-file says, you cannot resolve directories with. So, it cannot be used for
Roman