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

Christof Ressi info at christofressi.com
Sat Jan 8 18:31:43 CET 2022


I'll be travelling on Monday and can make a PR while sitting around.

>   (I'm currently afk, but isn't there already something like this in the filename handling parts of [file]?)
Yes, there is. [file isabsolute] should be trivial to implement.

> add [file cwd]
>    (and probably allow it to also *set* the cwd, not just query it)
Yes, why not. Should be easy to do with chdir() resp. _chdir()

> add [file patchdir]
>    (I would consider it a feature if that functionality was provided by [file] rather than [pdcontrol] (which could keep it for legacy reasons))
+1. On GitHub I have already proposed [file resolve]: 
https://github.com/pure-data/pure-data/issues/1539. The difference is 
that it resolves any path onto the patch directory. Sending a bang would 
output the patch directory itself (= [file patchdir]).

[file patchdir] would be the other way round: it's main purpose is to 
get the patch directory, but as an extra feature it should probably also 
allow to resolve a file path (because such a common task shouldn't 
require several objects).

Both would essentially provide the same things. IMO, [file resolve] 
would be more intuitive because after all that's what people likely want 
to do when they ask for the current patch directory.

Christof


On 08.01.2022 17:58, IOhannes m zmölnig wrote:
> Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi <info at christofressi.com>:
>>> I think what we actually need is something like [file isabsolute] and
>>> [file isrelative]! That would be a trivial but very useful addition.
>
> yes.
>
> the solution I like best so far is:
> - add [file isabsolute]
>    (I'm currently afk, but isn't there already something like this in the filename handling parts of [file]?)
> - add [file cwd]
>    (and probably allow it to also *set* the cwd, not just query it)
> - add [file patchdir]
>    (I would consider it a feature if that functionality was provided by [file] rather than [pdcontrol] (which could keep it for legacy reasons))
>
>
> mfg.sfg.jfd
> IOhannes
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list