Shell Programming and Scripting

It's also wise to use -- on the mv command line just in case of filename(s) starting with hypnen.

Yes, I recall writing a mv ksh script to allow files at the end like xargs:

Code:

#!/usr/bin/ksh
 
opts="$1"
dir="$2"
shift 
shift
mv $opts "$@" "$dir"

I wonder if absolute path costs time compared to relative, pawing through more dirs? Having dest on same mount is certainly a winner (no copying).

Yep that works. Can even be an embedded script:

Code:

ls | xargs -n101 sh -c 'dir=$1; shift; echo mv "$@" "$dir"' path_mv /appl/abcd/process_dir -f --

(Remove the echo to really execute!)

There are so many inconsistencies here I'm not sure where to start:
You say you have a directory full of "jpg" files, but the command you say works looks for "vgx" files; not "jpg" files???

You say the command:

Code:

mv  /appl/abcd/work_dir /appl/abcd/process_dir

fails with an E2BIG error, but that would not happen with this command. Was your command something more like one of the following instead?:

Code:

mv /appl/abcd/work_dir/*.jp*g /appl/abcd/process_dir
mv /appl/abcd/work_dir/*.vgx /appl/abcd/process_dir[
mv /appl/abcd/work_dir/* /appl/abcd/process_dir

If the command:

Code:

find ./appl/abcd/work_dir -name -type f -name "*.vgx" -exec mv -f {} /appl/abcd/process_dir \;

works (even though it should give you a syntax error and if that was fixed would only work if you are located in the root directory when you run it), what situation do you need to handle??? If what you really meant was that the above command doesn't work, try:

Code:

cd /appl/abcd/process_dir; find /appl/abcd/work_dir -type f -name "*.vgx" -exec mv -f {} . \;

Adding the cd command and changing the destination in the find -exec clause should let it run a little bit faster (but moving a few hundred thousand files one by one is not going to be fast by any stretch of the imagination. Others have already suggested ways to write a front-end to mv that will allow you to use -exec ... + instead of -exec ... \;.

If you don't have GNU mv, the following should still be pretty efficient:
Create a file named $HOME/bin/shift_mv containing:

Code:

#!/bin/ksh
dest="$1"
shift
mv -f -- "$@" "$dest"

and make it executable with:

Code:

chmod +x $HOME/bin/shift_mv

Then the command:

Code:

cd /appl/abcd; find work_dir -type f -name "*.vgx" -exec shift_mv process_dir {} +

should be relatively efficient.
(Note that shift_mv does not accept any options; so, if you want to give additional options to mv, you must put them in shift_mv; not in the find -exec clause.)

Safety first - always check exit status of a cd!

Code:

cd /appl/abcd/process_dir && find ...

Or

Code:

if cd /appl/abcd/process_dir
then
  find ...
  ...
fi

---------- Post updated at 06:57 PM ---------- Previous update was at 06:25 PM ----------

I don't see a problem with passing options - should work like other arguments.
find -exec might not execute scripts, then you need to explicitly invoke the ksh or sh program.

Code:

cd /appl/abcd/process_dir &&
find /appl/abcd/work_dir -type f -name "*.vgx" -exec sh shift_mv . -f -- {} +

and the shift_mv can be as small as my embedded path_mv above.

As long as shift_mv is executable and is in one of the directories named in $PATH:

Code:

find ... -exec path_mv ...

should work just fine without naming a shell to execute it.

You are correct in noting that mv options can be passed to shift_mv; they just won't be treated as options by shift_mv. Having the destination directory operand precede the options violates POSIX Utility Syntax Guideline 9 (All options should precede operands on the command line.), but if we use a SYNOPSIS like:

Code:

SYNOPSIS path_mv destination_directory other_mv_arguments...

it is a non-issue. And, of course, the name I suggested (and the path_mv you suggested) also violates POSIX Utility Syntax Guideline 2 (Utility names should include lowercase letters (the lower character classification) and digits only from the portable character set.) by including an underscore.

Is POSIX OK with "mvX OPTIONS DEST_PATH SOURCE_PATH(S)"? I always considered it good form to put the definite (one destination) before the variable (one or more sources).