Yeah - that might kinda be my fault - and a "holdover" from some of my original posts on using CREATEFOLDER that mrwul participated in... which had started a bit before I started "always" using a manual {dlgstring} prompt for the new folder name. Without a {dlgstring} combined with a path control code like {s} or {d}, you needed the HERE arg for (as an example) a hotkey or button that you wanted to copy/move data to a new folder in the 'current' folder. But of course, a "full path" provided by {d} or {s} and passed to the CREATEFOLDER argument trumps the HERE argument (which I rather think should be the case)... and since it always "just worked" I never bothered to the clean up the HERE args from any of my commands...
Woohoo, now I get to save a few extra BYTES of config file space by stripping out the HERE args from my commands...
Here's a version of that with the question pop-up removed:
@nofilenamequoting
dopusrt /CMD Copy MOVE TO HERE CREATEFOLDER "{d}"
@runmode hide
cmd.exe /C cd .. && rmdir "{s}"
Looking at this command some more, it's a little weird that it tells the copy command to move things "here" and then specifies a full, absolute path to the createfolder argument... There's surely a better way to do that... but, anyway, if it works, it works.[/quote]
Sofar it works fine, but I could not help it being puzzled by the CREATEFOLDER argument - as in fact nothing is being created at all.
So.. as test, I Deleted CREATEFOLDER , but then the above results in unexpected actions...
moving files residing in x:\source-files\test-subfolder
fm x:\source-files\test
to x:\dest-files
results in
not deleting the source files
instead moving the empty dest-files folder to the test-subfolder
quickly added the CREATEFOLDER again
(ah well, for me it's better to just stay away from all this )
The CREATEFOLDER argument also changes the destination path (think about it without that it'd just be moving the files "here", not into a subfolder of "here") even if it doesn't need to create that path because it already exists.