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..?
Message: 4Date: Sat, 8 Jan 2022 01:07:48 +0100From: Christof Ressi <info@christofressi.com>To: Pd-List <pd-list@lists.iem.at>Subject: Re: [PD] [file]: paths not relative to patchMessage-ID: <0d33e805-37ff-4988-d50e-29eb3d86d94e@christofressi.com>Content-Type: text/plain; charset=UTF-8; format=flowedIf 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.