RE: Weird behavior with find command when tarring files

  • From: <post.ethan@xxxxxxxxx>
  • To: "'Dave Herring'" <gdherri@xxxxxxxxx>, <jkstill@xxxxxxxxx>
  • Date: Tue, 18 Dec 2018 07:58:41 -0600

As they say in the Python world, explicit is better than implicit. I tend to 
just stay away from xargs. 

 

I can find original email so not sure if I got requirements 100% correct but I 
have solve the problem of only listing files or directories in a directory 
without looking in sub-dirs with a couple functions.

 

There are some external dependencies in this code, but easy to spot and remove 
without breaking things.

 

https://gist.github.com/ethanpost/94a0d2a17440a7f6acfbe52562e892d0

 

I would just write a look which lists the matching files and delete them with 
rm. Also above code should run on any Unix platform, no Linux dependencies as 
far as I know.

 

Using a function and a loop is also going to enable you to add logging easier 
if you want that.

 

Thanks,

Ethan

https://twitter.com/poststop

 

 

From: Dave Herring <gdherri@xxxxxxxxx> 
Sent: Monday, December 17, 2018 4:45 PM
To: jkstill@xxxxxxxxx
Cc: post.ethan@xxxxxxxxx; Amir.Hameed@xxxxxxxxx; ORACLE-L 
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: Weird behavior with find command when tarring files

 

Thanks for the tips with "xargs", Jared, although I don't quite understand what 
"xargs" is doing when "-0E" are involved.  The following was done on RHEL6.6:

 

Create 5 randomly named files with "x_" prefix.

% for ((i=1; i<=10; i++)); do touch x_`date +%N`.txt; done

% find . -maxdepth 1 -type f -print0

./x_287598645.txt./x_295644322.txt./x_303214626.txt./x_310464579.txt./x_317687226.txt./x_325071789.txt./x_332189678.txt./x_339226164.txt./x_346212508.txt./x_353403282.txt

 

Show that a "find" on "y_" names piped to "xargs -0 ls" still shows all files.  
This is because "ls" doesn't require [FILE] to be listed.

% find . -maxdepth 1 -type f -name 'y_*' -print0 | xargs -0 ls

x_287598645.txt  x_303214626.txt  x_317687226.txt  x_332189678.txt  
x_346212508.txt

x_295644322.txt  x_310464579.txt  x_325071789.txt  x_339226164.txt  
x_353403282.txt

 

Same test using "rm -v".  This fails because "rm" requires some value for it's 
parameter [FILE].

% find . -maxdepth 1 -type f -name 'y_*' -print0 | xargs -0 rm -v

rm: missing operand

Try `rm --help' for more information.

 

This is where I'm not clear.  I'd rather be safe and make sure "rm" is given a 
value but:

find . -maxdepth 1 -type f -name 'y_*' -print0 | xargs -0E rm -v

xargs: invalid option -- 'v'

Usage: xargs [-0prtx] [--interactive] [--null] [-d|--delimiter=delim]

       [-E eof-str] [-e[eof-str]]  [--eof[=eof-str]]

       [-L max-lines] [-l[max-lines]] [--max-lines[=max-lines]]

       [-I replace-str] [-i[replace-str]] [--replace[=replace-str]]

       [-n max-args] [--max-args=max-args]

       [-s max-chars] [--max-chars=max-chars]

       [-P max-procs]  [--max-procs=max-procs] [--show-limits]

       [--verbose] [--exit] [--no-run-if-empty] [--arg-file=file]

       [--version] [--help] [command [initial-arguments]]

 

It looks like "xargs" is assuming arguments for "rm" apply to itself and that 
only happens when the "-E" argument is used.  See the following 2 examples that 
run against files that ARE found:

% find . -maxdepth 1 -type f -name 'x_*5*' -print0 | xargs -0E rm -v

xargs: invalid option -- 'v'

Usage: xargs [-0prtx] [--interactive] [--null] [-d|--delimiter=delim]

       [-E eof-str] [-e[eof-str]]  [--eof[=eof-str]]

       [-L max-lines] [-l[max-lines]] [--max-lines[=max-lines]]

       [-I replace-str] [-i[replace-str]] [--replace[=replace-str]]

       [-n max-args] [--max-args=max-args]

       [-s max-chars] [--max-chars=max-chars]

       [-P max-procs]  [--max-procs=max-procs] [--show-limits]

       [--verbose] [--exit] [--no-run-if-empty] [--arg-file=file]

       [--version] [--help] [command [initial-arguments]]

 

% find . -maxdepth 1 -type f -name 'x_*5*' -print0 | xargs -0 rm -v

removed `./x_287598645.txt'

removed `./x_295644322.txt'

removed `./x_310464579.txt'

removed `./x_325071789.txt'

removed `./x_346212508.txt'

removed `./x_353403282.txt'

 

That last example works as I expected.

 

Dave

 

 

Other related posts: