I have a really simple little button that I use every day to move files up a level:
COPY MOVE to ..
GO BACK
The empty folder is then left selected, and I delete it manually, saying yes to are you sure etc.
I'd like to delete the now empty folder as part of the script, if possible.
I've tried just putting DELETE in as the third line but it looks as if it wants to delete everything in the folder rather than the currently selected (and now) empty folder.
The "." stands for the current folder (SELECT THIS may be redundant, but if it works, just leave it in), that is to be deleted, "Quiet" is suppressing the query.
Are you sure you want "Go BACK" and not "Go UP" or "Go UP BACK"?
The previous folder won't always be the parent folder.
If you want to delete the current folder you can also use "delete ." (as abr suggested) or "delete {sourcepath$}" which both avoid having to select things and worrying about the wrong thing being selected in some situations, which would be disastrous here.
You'll automatically be moved to the parent folder if the current folder is deleted, so you don't need to do that manually.
I think there may be a mistake here, or at least the risk of one. That would move everything up to the parent folder, then go to the parent folder (assuming parent=back; else it would go to some random folder), and then may delete the PARENT not the folder you were in. So it might delete everything it just moved, plus the rest of the parent folder (or some random folder from the navigation history, if it wasn't the parent).
(Hmm, actually, it might work if the Go command doesn't update the command's current folder, so . still refers to where you started off, but it still feels risky to me.)
This is more simple, and safer, I think:
Copy MOVE TO ..
Delete {sourcepath}
Note that even that is not entirely safe, since you may have a sub-folder with the same name as the current folder. Ideally you would only delete the current folder if it is empty after everything was moved.
You might also want to change Copy MOVE .. to Copy * MOVE TO .. so that it moves everything in the current folder, not just everything that is selected.
Now that you mention it, i also had a dubious feeling about automatizing delete commands . But it looked alright in the tests. & yeah, it should've been UP instead of BACK, in case the user jumped otherwise to that folder, for example via the history or an alias.
I've been using MoveToParentFolder (3rd code posted) for years and haven't had any problems so far. I like that it cancels the delete if any files are left behind (maybe do to duplicates that you decide not to move).
Because it is an auto move and delete command, I added the @confirm command.
Is there a way to pull the parent path off of individual files instead of a lister? "COPY MOVE to .." does not work properly if you are using a flat view or working with a file collection. By properly, I mean moving files to their respective parent folders.
Thank you for your help.
I used this: COPY MOVE TO {filepath|..}
That throws an error that says that the source and destination are the same. I tried it with a collection, flat view, and just plain folder. Did I get that right?
Oh, hang on, the source and destination are the same. The error message is correct. (We're so used to using {sourcepath|..} for other things that we've both assumed {x|..} would work without thinking about exactly what we were doing.)
{filepath$|..} is the parent folder of the file being moved, which is where the file already is.
{filepath$|....} is the folder we want:
Copy MOVE FILE {filepath$} TO {filepath$|..\..}
If that still has problems, try running it via dopusrt to force it to consider each file separately:
dopusrt /acmd Copy MOVE FILE {filepath$} TO {filepath$|..\..}
That would move everything up to the parent folder, then go to the parent folder (assuming parent=back; else it would go to some random folder), and then may delete the PARENT not the folder you were in. So it might delete everything it just moved, plus the rest of the parent folder (or some random folder from the navigation history, if it wasn't the parent).
. But it looked alright in the tests. & yeah, it should've been UP instead of BACK, in case the user jumped otherwise to that folder, for example via the history or an alias.
(We're so used to using {sourcepath|..} for other things that we've both assumed {x|..} would work without thinking about exactly what we were doing.)