[PD] [file]: paths not relative to patch

[Roman Haefeli]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220107/be9e0d3a/attachment.sig>