I agree with Roman's point that "current working directory" as an idea is different, depending on the user. For some, it will be relative to the patch, for others it will be relative to the shell (and the resulting programs launched by it). I agree it makes technical sense that [file] would be relative to the Pd process, knowing the C api behind it, but for many it's a bit of friction for sure since it's something that now works different from other objects which handle paths implicitly. Additionally, I think it's perhaps a stretch to assume most beginners are aware of how shells and paths work.
If it were up to me, I would make [file] work like the other objects and treat relative paths as relative to the canvas. OTOH I know this could complicate the implementation. 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. ;)
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..?
On Jan 8, 2022, at 1:07 AM, pd-list-request@lists.iem.at wrote:
Message: 4 Date: Sat, 8 Jan 2022 01:07:48 +0100 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] [file]: paths not relative to patch Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d94e@christofressi.com mailto:0d33e805-37ff-4988-d50e-29eb3d86d94e@christofressi.com> Content-Type: text/plain; charset=UTF-8; format=flowed
If I pass a relative path to such an utility, I want it to resolve to the current working directy and *not* to the Pd patch itself.
In practice, I almost wrap such utilities in a shell script anyway and there I would turn relative path arguments into absolute paths before passing them on to Pd. But I just wanted to show that the current directory is not completely useless.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
I, personally, find the documentation of [file] quite good.
Yes, but it doesn't mention at all that relative paths are resolved to the current working directory (or any other way the OS prefers). This is goes against an established pattern and would be surprising to most users (although it's not wrong).
I think file-help.pd should mention prominently that relative file paths are generally *not* resolved to the canvas environment and you have to use either [file which] or [dir( -> [pd control]. Hopefully, the latter can soon be replaced by something like [file resolve]: https://github.com/pure-data/pure-data/issues/1539
The confusion is my fault... "." never really meant current working directory, it just means "THIS directory here". I.E., it could mean any #$^#$ thing at all :)
M
On Sat, Jan 08, 2022 at 10:42:35AM +0100, Dan Wilcox wrote:
I agree with Roman's point that "current working directory" as an idea is different, depending on the user. For some, it will be relative to the patch, for others it will be relative to the shell (and the resulting programs launched by it). I agree it makes technical sense that [file] would be relative to the Pd process, knowing the C api behind it, but for many it's a bit of friction for sure since it's something that now works different from other objects which handle paths implicitly. Additionally, I think it's perhaps a stretch to assume most beginners are aware of how shells and paths work.
If it were up to me, I would make [file] work like the other objects and treat relative paths as relative to the canvas. OTOH I know this could complicate the implementation. 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. ;)
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..?
On Jan 8, 2022, at 1:07 AM, pd-list-request@lists.iem.at wrote:
Message: 4 Date: Sat, 8 Jan 2022 01:07:48 +0100 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] [file]: paths not relative to patch Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d94e@christofressi.com mailto:0d33e805-37ff-4988-d50e-29eb3d86d94e@christofressi.com> Content-Type: text/plain; charset=UTF-8; format=flowed
If I pass a relative path to such an utility, I want it to resolve to the current working directy and *not* to the Pd patch itself.
In practice, I almost wrap such utilities in a shell script anyway and there I would turn relative path arguments into absolute paths before passing them on to Pd. But I just wanted to show that the current directory is not completely useless.
Dan Wilcox @danomatika <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika&a... > danomatika.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com_&d=Dw... > robotcowboy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com_&d=D... >
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
-
Christof Ressi -
Dan Wilcox -
Miller Puckette -
Roman Haefeli