On Fri, 2022-01-07 at 23:20 +0100, Christof Ressi wrote:
And what would you *do* want to use the current working directory?
The patch's own directory, like all other file writing objects do.
Generally, [file] doesn't do any magic.
I don't consider starting from a sane working directory magic.
If you want to resolve an existing file using Pd's canvas: use [file which]. If you want create a new file relative to the patch, use [dir( -> [pdcontrol].
That's what I do now. That's the easy part. The less easy part is reliably detecting whether a given path is relative. But knowing that even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :).
Yeah, this works fine for finding already existing files, but as the help-file says, you cannot resolve directories with. So, it cannot be used for
But that's a general limitation of Pd. At the moment, it can only resolve files but not directories. This limitation can, of course, be removed and then [file which] will work as expection.
Thinking about it some more, this isn't a severe limitation. As I understand, it looks into all search paths. However, when I configure 'myblobs' as directory, I don't mean to write to any other 'myblobs' directory that might be returned by [file which]. I think [file which] shouldn't be for finding directories to write new files into. It should only be used for finding existing files.
I only need to append the configured path to the patch's path if the configured path is a relative path. But how can I reliably detect that?
I think what we actually need is something like [file isabsolute] and [file isrelative]! That would be a trivial but very useful addition.
I think those would be valuable additions.
Roman
And what would you *do* want to use the current working directory?
The patch's own directory, like all other file writing objects do.
Sorry, made a typo there. I meant: what would you do if you *do* want to use the current working directory?
Generally, [file] doesn't do any magic.
I don't consider starting from a sane working directory magic.
How is the current working directory not a sane directy? Again, [file] doesn't do anything special. It treats relative file paths just like the OS shell would do.
If you want to resolve an existing file using Pd's canvas: use [file which]. If you want create a new file relative to the patch, use [dir( -> [pdcontrol].
That's what I do now. That's the easy part. The less easy part is reliably detecting whether a given path is relative. But knowing that even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :).
That's what I was going to recommend. After all, [file isabsolute] would likely just use sys_isabsolutepath() under the hood :-)
On Fri, 2022-01-07 at 23:41 +0100, Christof Ressi wrote:
And what would you *do* want to use the current working directory?
The patch's own directory, like all other file writing objects do.
Sorry, made a typo there. I meant: what would you do if you *do* want to use the current working directory?
Ah, now I understand your question. But I don't think it is a valid question. I see no point in using what currently is the working directory of Pd. Depending on how Pd is started, it uses a different working directory without the user necessarily intending to do so. When I double-click a Pd file, the working directory is set to my user home. When I launch Pd from terminal or by script, anything might be the resulting working directory. If I do use that in a patch, I must make assumptions about how the user running my patch is starting Pd. I do not think that makes any sense, therefor I don't see how Pd's start location has any sensible meaning in everyday patching.
I'm asking you back: What do you do if you want to write relative to Pd's start location with [text], [textfile], [table], [soundfiler], [array]? You currently cannot do that and apparently this is no problem, otherwise people would have requested it.
Generally, [file] doesn't do any magic.
I don't consider starting from a sane working directory magic.
How is the current working directory not a sane directy?
See above. It's just not useful for anything.
Again, [file] doesn't do anything special. It treats relative file paths just like the OS shell would do.
And? It's usually not part of the Pd workflow to switch to a specific directory before starting Pd. More often, Pd is launched by double- clicking a patch. This is very unlike shell, where switching directories is part of the experience and where there's an expectation it has an impact on the outcome ('ls' without args). This does not apply to Pd at all. Thus, all file writing objects are written so that they write relative to the patch. That's an already established pattern. I don't see why you are arguing against it.
If you want to resolve an existing file using Pd's canvas: use [file which]. If you want create a new file relative to the patch, use [dir( -> [pdcontrol].
That's what I do now. That's the easy part. The less easy part is reliably detecting whether a given path is relative. But knowing that even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :).
That's what I was going to recommend.
It's clumsy and wrong. It'll detect my sub-directory named 'C:' as an absolute path while I was intending it as a relative path.
use the current working directory?
Ah, now I understand your question. But I don't think it is a valid question. I see no point in using what currently is the working directory of Pd. Depending on how Pd is started, it uses a different working directory without the user necessarily intending to do so.
There are certainly scenarios where this is exactly what you want, e.g. when Pd is used as command line utily (I have personally written such utilities). 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.
Thus, all file writing objects are written so that they write relative to the patch. That's an already established pattern. I don't see why you are arguing against it.
I acknowledge that it's an established pattern. Actually, [file] could have added an object [file cwd] to get the currenty working directy if someone needs it and use the Pd patch location as the default.
On the other hand, I understand that [file] wants to be a low-level filesystem API and not apply any magic. It's really design decision.
I'm asking you back: What do you do if you want to write relative to Pd's start location with [text], [textfile], [table], [soundfiler], [array]? You currently cannot do that and apparently this is no problem, otherwise people would have requested it.
Yes, this is a limitation. And actually an argument for a [file cwd] object.
How is the current working directory not a sane directy?
See above. It's just not useful for anything.
See above. It is.
even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :).
That's what I was going to recommend.
It's clumsy and wrong. It'll detect my sub-directory named 'C:' as an absolute path while I was intending it as a relative path.
Ah yes, on the patch level you don't know if you're on Windows. On Windows, ':' is a reserved character and can only appear as part of a drive letter.
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.
On 08.01.2022 00:49, Christof Ressi wrote:
use the current working directory?
Ah, now I understand your question. But I don't think it is a valid question. I see no point in using what currently is the working directory of Pd. Depending on how Pd is started, it uses a different working directory without the user necessarily intending to do so.
There are certainly scenarios where this is exactly what you want, e.g. when Pd is used as command line utily (I have personally written such utilities). 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.
Thus, all file writing objects are written so that they write relative to the patch. That's an already established pattern. I don't see why you are arguing against it.
I acknowledge that it's an established pattern. Actually, [file] could have added an object [file cwd] to get the currenty working directy if someone needs it and use the Pd patch location as the default.
On the other hand, I understand that [file] wants to be a low-level filesystem API and not apply any magic. It's really design decision.
I'm asking you back: What do you do if you want to write relative to Pd's start location with [text], [textfile], [table], [soundfiler], [array]? You currently cannot do that and apparently this is no problem, otherwise people would have requested it.
Yes, this is a limitation. And actually an argument for a [file cwd] object.
How is the current working directory not a sane directy?
See above. It's just not useful for anything.
See above. It is.
even Pd does it somewhat clumsily, I'll stick to the clumsy solution (checking for / and :).
That's what I was going to recommend.
It's clumsy and wrong. It'll detect my sub-directory named 'C:' as an absolute path while I was intending it as a relative path.
Ah yes, on the patch level you don't know if you're on Windows. On Windows, ':' is a reserved character and can only appear as part of a drive letter.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Roman Haefeli