…which it doesn’t according to my tests with PL7 on macOS Sonoma
./test
writes to a subfolder
/test
same as above
/test/test/test
writes to a sub-sub-subfolder
Wow. That is definitely inconsistent.
Well, we’re comparing PL Win vs. PL Mac. They are quite different in other respects too.
I suppose that DxO chose to stick to expected behaviour of Mac users rather than CLI style entries…
Hopefully this answers for OP’s question.
I just ran a couple of tests on my Mac…
… tries to export to a folder called Export in the root folder. This fails, as it should, due to permissions error.
… exports to an Export folder at the same level as the folder containing the image file.
… exports to a sub-folder named Export in the the folder that contains the image file
… also exports to a sub-folder named Export in the the folder that contains the image file
… also exports to a sub-folder named Export in the the folder that contains the image file
So the last three variants all do exactly the same thing. That is just not logical, even though it might seem convenient that a user doesn’t have to be precise. It could cause mistakes.
But for some system calls, Windows internally changes slashes to backslashes. This works for opening a file, changing directory, but does not work for creating a directory or filename completion at the CMD prompt. It was a hidden feature already in some MS DOS versions.
waohh. I wasn’t aware relative path is working here. Great !
The possibility below shouldn’t be lost if interface is changed (relative path to any level) :
@Joanna Have I missed something but my standard export on Win is this
Which creates the subfolder “Out” within the image folder which I believe is what the topic author wanted isn’t it!?
