On Sat, 2022-01-08 at 10:42 +0100, Dan Wilcox wrote: > > If it were up to me, I would make [file] work like the other objects > and treat relative paths as relative to the canvas.
I agree with Christof that this probably not a good idea after pd 0.52 has been released. > OTOH I know this could complicate the implementation. Yeah, I see that now. I thought 'chdir(canvas_getdir(canvas_getcurrent))' would probably do, but since [file] runs directly in Pd it would apply to the whole Pd instance, which is probably not what anyone wants. My external [command] does that, but after forking, so it doesn't apply to the parent thread. This allows to call scripts lying near the patch containing [command]. > I think at the very least, this difference needs to be well > documented with the requisite canvas-oriented approaches documented. > Forgive me if they are already as I've not used [file] yet, but > Roman's question indicates to me perhaps not everything is covered > yet. ;) It came up because I noticed [file] breaks established patterns regarding relative paths. Improving the documentation alone wouldn't help with making write files near the patch easier. I, personally, find the documentation of [file] quite good. > Another approach is to provide a very explicit option to get the > patch canvas location which fits into the api ala [file patchdir] or > [file canvasdir]. I know this is probably redundant to [pdcontrol] > but perhaps helps with the distinction..? The hard part is not getting the canvas directory, as that is already covered, but simply writing a file near the patch involves quite a lot of patching right now. What _would_ help is Christof's suggestion of [file resolve] if it has the ability to resolve to relative to the patch. [symbol myblobs/newblob.dat( | [file resolve -canvas] | [open $1 c( | [file handle] See: https://github.com/pure-data/pure-data/issues/1536#issuecomment-1007849130 Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list