Re: [Non-DoD Source] Re: Please advise work around or bug fix

[Bob Proulx]

Bob Proulx wrote:
> Then I would use this following technique since it effectively exactly
> answers the question you asked.  Try this:
>
>     find . -size +1k -exec sh -c 'ls -1sd "$@"' sh {} +

Berny asked me why I chose to do it that way instead of the simpler
and more direct following.

    find . -size +1k -exec ls -1sd {} +

And the answer is that I was having an off day and was thinking of a
restriction that was not there!  Berny was of course correct that the
above is simpler than what I suggested.  I am not sure why I was not
thinking correctly at that time.  While useful that sh -c technique
was simply introducing a useless shell process in my suggestion.

The time when it is advantageous to use a shell as I had suggested is
when one needs to do something in a different order.  For example "mv"
uses the last program argument on the right side as the target
directory.  Therefore trying to get the target directory last is
problematic.  However it can be done using the above technique this
way.

    find . -size +1k -exec sh -c 'echo mv "$@" ../somedir/' sh {} +

That's one of the times when the extra shell is advantageous.
Otherwise it is just an extra shell.  As my erroneous thinking caused
me to suggest.  Sorry about that!

As an aside: GNU mv has the --target-directory=DIR for this reason but
that is a non-standard extension.  But as an example of using it then
this is the better way to avoid the extra shell process.

    find . -size +1k -exec echo mv --target-directory=../somedir/ {} +

In Berny's expansive posting I missed seeing this suggestion there.

Berny wrote:
> Another alternative is to let find(1) directly print the file size and file 
> name.
> This avoid the race condition.
> 
>   $ find . -size +1k -printf '%s %f\n'

That's a fine suggestion when using GNU find.  It must be GNU find as
that is a GNU extension.  Won't work on the *BSD systems.  But if so
then it is a very efficient method.

Bob