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