On Fri, 2022-01-07 at 23:20 +0100, Christof Ressi wrote: > > > > And what would you *do* want to use the current working directory?
The patch's own directory, like all other file writing objects do. > Generally, [file] doesn't do any magic. I don't consider starting from a sane working directory 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]. That's what I do now. That's the easy part. The less easy part is reliably detecting whether a given path is relative. But knowing that even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :). > > > 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. Thinking about it some more, this isn't a severe limitation. As I understand, it looks into all search paths. However, when I configure 'myblobs' as directory, I don't mean to write to any other 'myblobs' directory that might be returned by [file which]. I think [file which] shouldn't be for finding directories to write new files into. It should only be used for finding existing files. > > 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. I think those would be valuable additions. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
