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

[Christof Ressi]

> 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list