RE: Weird behavior with find command when tarring files

From: <post.ethan_at_gmail.com>
Date: Tue, 18 Dec 2018 07:58:41 -0600
Message-ID: <01e701d496d9$c92dab30$5b890190$_at_gmail.com>



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_at_gmail.com> Sent: Monday, December 17, 2018 4:45 PM
To: jkstill_at_gmail.com
Cc: post.ethan_at_gmail.com; Amir.Hameed_at_xerox.com; ORACLE-L <oracle-l_at_freelists.org> 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    

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 18 2018 - 14:58:41 CET

Original text of this message