Dear list
When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch. This is unusual, as [text], [array], [table], [soundfile], etc. resolve relative paths relative to the patch. Also, I don't quite see the use case for relative to Pd's start. At least, _I_ never cared about where Pd was started from and when working on a patch meant to run on other people's computer I don't make any assumptions about Pd's start location. To me, relative to Pd's start location is pretty useless.
Now, it's really unlucky I spotted this only now after 0.52 has been released. Fixing it would break backwards-compatibility. OTOH, the fact this hasn't been reported yet makes me assume [file] with relative paths wasn't used that much yet. If this is going to be fixed, it should be fixed rather soon.
Best, Roman
On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote:
Dear list
When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch.
I'd like to work-around this with [dir(-[pdcontrol] which returns the directory of the patch which can be used to construct an absolute path with a given relative path. However, the hard part is to reliably detect whether a given path is relative. I thought I could check for absolute paths by checking if the first byte is a '/' OR the second byte is a ':'. However, it turns out 'C:' is a perfectly valid name for a directory on ext4, for instance. Doing that detection reliably turns out to be quite hard and probably involves detecting the OS.
Or am I overlooking a simpler vanilla way? Roman
Have you tried [file which] ?
Le ven. 7 janv. 2022 à 17:58, Roman Haefeli reduzent@gmail.com a écrit :
On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote:
Dear list
When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch.
I'd like to work-around this with [dir(-[pdcontrol] which returns the directory of the patch which can be used to construct an absolute path with a given relative path. However, the hard part is to reliably detect whether a given path is relative. I thought I could check for absolute paths by checking if the first byte is a '/' OR the second byte is a ':'. However, it turns out 'C:' is a perfectly valid name for a directory on ext4, for instance. Doing that detection reliably turns out to be quite hard and probably involves detecting the OS.
Or am I overlooking a simpler vanilla way? Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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. The [file] interface itself is just a thin wrapper over the POSIX file API and therefore agnostic of Pd's search paths.
As Antoine has already mentioned, use [file which] if you want to resolve a relative path to the canvas environment.
Christof
On 07.01.2022 17:34, Roman Haefeli wrote:
Dear list
When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch. This is unusual, as [text], [array], [table], [soundfile], etc. resolve relative paths relative to the patch. Also, I don't quite see the use case for relative to Pd's start. At least, _I_ never cared about where Pd was started from and when working on a patch meant to run on other people's computer I don't make any assumptions about Pd's start location. To me, relative to Pd's start location is pretty useless.
Now, it's really unlucky I spotted this only now after 0.52 has been released. Fixing it would break backwards-compatibility. OTOH, the fact this hasn't been reported yet makes me assume [file] with relative paths wasn't used that much yet. If this is going to be fixed, it should be fixed rather soon.
Best, Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote:
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.
I was wondering how objects before [file] did select a path for writing. If I am not mistaken, [text] uses canvas_makefilename() for converting a given path or filename to an absolute path. It first checks if the given path is absolute by checking for '/' (first byte) or ':' (second byte) and prepends the canvas' own directory to it, if is relative. It's basically a clumsy way to switch the working directory to the patch's directory. And it's what I have to do now when using [file].
I need to be enlightened: What is the benefit of using Pd's start location as working directory in [file]?
Roman
On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote:
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
Sorry, I somehow hit 'send' in the middle of a sentence. I meant to say: [file which] doesn't work for resolving relative directories. Obviously, you also cannot use it for non-existing files, a.k.a files you want to create. This means, using [file] for writing files near the patch is a rather convoluted enterprise.
Roman
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.
And what would you *do* want to use the current working directory?
Generally, [file] doesn't do any magic. If you want to resolve an existing file using Pd's canvas: use [file which]. If you want create a new file relative to the patch, use [dir( -> [pdcontrol].
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
But that's a general limitation of Pd. At the moment, it can only resolve files but not directories. This limitation can, of course, be removed and then [file which] will work as expection.
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?
I think what we actually need is something like [file isabsolute] and [file isrelative]! That would be a trivial but very useful addition.
Christof
I think what we actually need is something like [file isabsolute] and [file isrelative]! That would be a trivial but very useful addition.
Just made a feature request: https://github.com/pure-data/pure-data/issues/1535
Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi info@christofressi.com:
I think what we actually need is something like [file isabsolute] and [file isrelative]! That would be a trivial but very useful addition.
yes.
the solution I like best so far is:
- add [file isabsolute] (I'm currently afk, but isn't there already something like this in the filename handling parts of [file]?)
- add [file cwd] (and probably allow it to also *set* the cwd, not just query it)
- add [file patchdir] (I would consider it a feature if that functionality was provided by [file] rather than [pdcontrol] (which could keep it for legacy reasons))
mfg.sfg.jfd IOhannes
I'll be travelling on Monday and can make a PR while sitting around.
(I'm currently afk, but isn't there already something like this in the filename handling parts of [file]?)
Yes, there is. [file isabsolute] should be trivial to implement.
add [file cwd] (and probably allow it to also *set* the cwd, not just query it)
Yes, why not. Should be easy to do with chdir() resp. _chdir()
add [file patchdir] (I would consider it a feature if that functionality was provided by [file] rather than [pdcontrol] (which could keep it for legacy reasons))
+1. On GitHub I have already proposed [file resolve]: https://github.com/pure-data/pure-data/issues/1539. The difference is that it resolves any path onto the patch directory. Sending a bang would output the patch directory itself (= [file patchdir]).
[file patchdir] would be the other way round: it's main purpose is to get the patch directory, but as an extra feature it should probably also allow to resolve a file path (because such a common task shouldn't require several objects).
Both would essentially provide the same things. IMO, [file resolve] would be more intuitive because after all that's what people likely want to do when they ask for the current patch directory.
Christof
On 08.01.2022 17:58, IOhannes m zmölnig wrote:
Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi info@christofressi.com:
I think what we actually need is something like [file isabsolute] and [file isrelative]! That would be a trivial but very useful addition.
yes.
the solution I like best so far is:
- add [file isabsolute] (I'm currently afk, but isn't there already something like this in the filename handling parts of [file]?)
- add [file cwd] (and probably allow it to also *set* the cwd, not just query it)
- add [file patchdir] (I would consider it a feature if that functionality was provided by [file] rather than [pdcontrol] (which could keep it for legacy reasons))
mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 8. Jänner 2022 18:31:43 MEZ schrieb Christof Ressi info@christofressi.com:
Both would essentially provide the same things. IMO, [file resolve] would be more intuitive because after all that's what people likely want to do when they ask for the current patch directory.
I dunno. iirc, [file which] was originally named [file resolve] but I started a hearty dislike for this name, as I think its rather confusing.
mfg.sfg.jfd IOhannes
Then let's go with [file patchdir] for now. I don't care too much about the name :-)
A bang would unsurprisingly output the patch directory.
You can also send a path name as a symbol. If the path is relative, [file patchdir] will resolve it to the patch directory. Absolute paths are passed unchanged.
Should we also provide a creation argument and float message for the parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> [file patchdir] would output the parent patch directory, etc. This would make [pdcontrol]'s [dir( method entirely obsolete.
Christof
On 08.01.2022 18:46, IOhannes m zmölnig wrote:
Am 8. Jänner 2022 18:31:43 MEZ schrieb Christof Ressi info@christofressi.com:
Both would essentially provide the same things. IMO, [file resolve] would be more intuitive because after all that's what people likely want to do when they ask for the current patch directory.
I dunno. iirc, [file which] was originally named [file resolve] but I started a hearty dislike for this name, as I think its rather confusing.
mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 8. Jänner 2022 19:11:43 MEZ schrieb Christof Ressi info@christofressi.com:
Then let's go with [file patchdir] for now. I don't care too much about the name :-)
A bang would unsurprisingly output the patch directory.
You can also send a path name as a symbol. If the path is relative, [file patchdir] will resolve it to the patch directory. Absolute paths are passed unchanged.
probably [file patchpath] then? a "path" can be both a file and a directory, whereas a "dir" can only be the latter
mfg.sfg.jfd IOhannes
On Sat, 2022-01-08 at 19:11 +0100, Christof Ressi wrote:
Should we also provide a creation argument and float message for the parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> [file patchdir] would output the parent patch directory, etc. This would make [pdcontrol]'s [dir( method entirely obsolete.
Nice idea. The ability to query upper level patches is quite a powerful feature.
Roman
-
Antoine Rousseau -
Christof Ressi -
IOhannes m zmölnig -
Roman Haefeli