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

[Roman Haefeli]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220108/f3bc300f/attachment.sig>