BTW: I hardly ever cd, even in scripts, as I found it hindered my productivity and led to errors. The problem with cd is then, commands are not reusable. The cd is really a typing shorthand. Effectively, it is in competition with command recall. Absolute paths are not much of a burden if they are not typed. UNIX ksh life was more consistent, error-free, better if I used X cut/paste, command recall & editing: set -o vi/viraw w/export HISTSIZE=32767, even archiving .sh_history occasionally for my tools that recall history. I even wrote a vi wrapper so my xterm scroll history (also set real big) was not overwritten and the return is always zero (so results are not discarded). Since I never leave $HOME, I can use relative paths for all common things, some through my own sym-links, and absolute for things less frequent. All my history is rerunnable. If it needs cd, I do: (cd ... ; .... )
---------- Post updated at 11:20 AM ---------- Previous update was at 11:12 AM ----------
My solution moves one dir at a time, not one file, which might be a bit faster and lower overhead.
It also ensures the target is present. It does not check to see if the source files are present, but that is not worth scripting or easy to script cheaply.
If you get a huge dir, when someone allows too many files to expand the directory inode, the speed difference is very substantial. With my plan, you are going to traverse that directory:
- once in find to find the archive/,
- once in ksh to find the source files for the mv command line, and then
- once (for every file?) inside mv to find the archive\
- once for every file inside mv, but just far enough through the directory to find that file and overwrite that part of the directory.