Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

What's New doesn't mention copydir movedir

Considering I've been asking for them for a decade or so, perhaps you should have let me test them. I can't imagine what people could have complained about. The suggestion got lots of support in the forum and feedback over the years and it is standard in unix shells. Really, if people don't like them, they don't have to use them. But, why make life difficult for those of us who have a use for them?
 
David,

The problem was that, as implemented, they didn't actually move directories at all, but rather, they moved the contents of a directory to another directory.

Not useless, but not as useful as being able to actually move directories safely and consistently.
 
The problem was that, as implemented, they didn't actually move directories at all, but rather, they moved the contents of a directory to another directory.

Not true (but I got tired of arguing the point with the beta testers). The beta testers wanted the COPYDIR / MOVEDIR commands to behave differently depending on the (usually unknown) existence or absence of the target. I refused, and removed the commands.
 
Moved the contents? I'm not sure what that means. But, if they didn't do what the feedback suggestion asked for, then why not implement what was really asked for?
 
David,
An idea is insufficient, even if a great one. Implementation matters more. But, if a particular implementation breaks a paradigm, it may be difficult to work around conflicting expectations. I suspect something like that may have happened here.

As an example, there are patterns developed from years of using 4DOS-TCC for file and folder manipulation. One expectation is that target allows a rename. Another expectation is that target only specify the parent folder and not require a duplicate of the source folder name. These are just a couple of examples. But, unless the many possibilities are planned for, some expectations may be met, but not others, thus the conflicting expectations possible in an implementation.
 
Do you mean you want to both copy/move and change the name in the same command? That wasn't the suggestion. The commands are for copying and moving directories, not renaming them. There is already a command to rename things. In other words, they should be command line versions of what you can do with drag and drop in Explorer. If the names confuse you, then name them "foo" and "bar" so you don't get confused. I can always alias them to something I like.
 
Do you mean you want to both copy/move and change the name in the same command? That wasn't the suggestion. The commands are for copying and moving directories, not renaming them. There is already a command to rename things.
That was an example of the mixed expectations. Some expected to specify the parent folder and some expected to specify a new directory name/location (but not the parent).
 
If you want to change one directory's name and location, just use RENAME. I don't see why useful commands should be dropped just because some people didn't understand their purpose. You could change the names: MoveDirToParent, CopyDirToParent. And don't try to tell me that the existing commands and their options are always intuitive.
 
If you want to change one directory's name and location, just use RENAME.
If RENAME were sufficient, MOVEDIR would not be necessary. After all, that is what the unix mvdir does: "Moves (renames) a directory." Yet, it was still suggested. While removal of all/most of the confusions and the meeting of sufficient expectations may be possible, it might take more time/work than was available for this version and, given Rex's comment, perhaps more work than it was worth. Those are my guesses and the best I can offer.
 
Beta testers voted for a MOVEDIR/COPYDIR behaviour like you get from Explorer: Name the DIR to move/copy, name the destination and presto. Everything else, e.g. a rename, could have been handled by switches, if not separate commands.

On the other hand was a MOVEDIR/COPYDIR that expected you to name the whole destination path including the resulting DIR's name, so that a "MOVEDIR foo c:" resulted in all files from foo in the root dir of C:, not in C:\foo.

And since Rex expects an opinion exchange to work so that everybody exchanges his own opinion for Rex's, he removed the commands, "never to return (???)". :-)
 
I find this situation amusing. I have been an avid user of robocopy ever since I first discovered it over a decade ago. robocopy (possibly the most useful program Microsoft ever created) works the way Rex's MOVEDIR/COPYDIR commands. When I use rsync in Linux, it always throws me because it doesn't work that way. What's really sad is that if there were a command that didn't work the way I wanted it to, I'd write a batch file or alias, whatever, to make it do what I want (e.g., I have an alias called "robomove" which does what you would expect).

I'm sorry those commands are gone, but as long as I have good old robocopy, I can do what I want.
 
The whole point of the request was so that you didn't have to name the target and so you could move multiple directories. If that isn't what Rex implemented, then what he implemented was not what was requested/desired.

This is something that is reasonably simple to do with Explorer, but not so easy (or very difficult) to do at the command line. (It also seems to be difficult to do with the TC folder view. The folder view seems to copy by default while Explorer moves. And, you can't right-click and drag.)

Maybe a better name would be DirPaste, which would do a copy and paste. You could have a switch if you wanted cut and paste. Or, you could have DirCopyPaste and DirCutPaste.

I didn't know unix had mvdir. Is that relatively new? I haven't used unix seriously for many years. Regardless, I'm not suggesting we duplicate the unix commands.
 
On the other hand was a MOVEDIR/COPYDIR that expected you to name the whole destination path including the resulting DIR's name, so that a "MOVEDIR foo c:" resulted in all files from foo in the root dir of C:, not in C:\foo.
Can't we already do that by "move /s foo\* c:\"?
 
Beta testers voted for a MOVEDIR/COPYDIR behaviour like you get from Explorer: Name the DIR to move/copy, name the destination and presto. Everything else, e.g. a rename, could have been handled by switches, if not separate commands.

Unfortunately, this was not at all clear. On the beta forum, Rex said that as far as he understood, he had implemented it exactly the way the original poster wanted it. I went back to uservoice and read David Marcus' original post, and indeed I found that Rex's understanding was not precluded. That is, although when I voted for the suggestion I envisioned it working as Klaus has stated here, Rex's understanding is equally valid. In retrospect, if the original post had been more precise in delineating the specific feature, it would have prevented this misunderstand from the get-go. But as it is, it is unfortunately not unequivocal that "Beta testers voted MOVEDIR/COPYDIR behaviour like you get from Explorer".
 
On the beta forum, Rex said that as far as he understood, he had implemented it exactly the way the original poster wanted it. I went back to uservoice and read David Marcus' original post, and indeed I found that Rex's understanding was not precluded.
The suggestion on Uservoice does say "manipulate directories", not manipulate their contents. And my first comment on uservoice says, "I often just fire up Windows Explorer. Note that I want to copy/move the directories, not their contents." And there were several threads on the forum discussing this. Unfortunately, the links to the threads that are in the comments on Uservoice don't seem to work anymore, but I expect the threads wouldn't be hard to find, if they still exist. Since there was ample discussion in those threads of what was desired (with many examples over many years), it seemed unnecessary to give a detailed spec in the suggestion. No one in any of those threads ever requested some other sort of behavior. It is sad that people would discuss whether something was implemented as I wanted it without asking me.

Since something other than what was suggested was implemented, the logical course would be to implement what was actually suggested.

I'd do it myself, but it isn't so easy to do well in a btm, and would probably be a good deal of work to do in a separate app. Plus, it isn't that hard to do in Explorer, so it is hard to work up the motivation.
 
Since there was ample discussion in those threads of what was desired (with many examples over many years), it seemed unnecessary to give a detailed spec in the suggestion.

Fair enough. I was not aware of the other discussions.

I'd do it myself, but it isn't so easy to do well in a btm, and would probably be a good deal of work to do in a separate app. Plus, it isn't that hard to do in Explorer, so it is hard to work up the motivation.

A very simplistic COPYDIR/MOVEDIR wouldn't be very hard to implement in a BTM. But to do a proper and robust implementation as Rex does - with a /N option and /Q option and support for file lists and FTP support and regular expression support - is way beyond a simple BTM. I do hope Rex agrees at the least to restore the COPYDIR/MOVEDIR combo as he implemented them.
 
I have no objection to TCC including whatever was implemented (not that I've seen it). But, I'd still like what I suggested. I've given some suggestions for what the command(s) could be called in this thread.
 
Besides "DirPaste" (or "DirCopyPaste", "DirCutPaste"), "DirDrag" is a possible name. Or, "DirDragDrop". Or "Folder" instead of "Dir". Or "PasteDir" or "DragDir".
 

Similar threads

Back
Top