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

[Roman Haefeli]

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
-------------- 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/20220108/c93f9bb7/attachment.sig>