Re: Purging files in the IFS by date (aka which Scott Klement utility to use :)

Charles,

The \ character is an escape character. It tells the shell to pass the character that follows it (the * in your example) as-is to the program instead of interpreting it by it's special meaning (wildcard)

The goal here is to let the 'find' program handle the wildcard instead of the shell.

So when you have

find . -name \*.java

it passes the * to the program -- therefore letting the program take care of the wildcard. If you had left off the \, the shell would've expanded it into a list of filenames, and passed that list to to 'find' -- which wouldn't work properly in this situation.

Why didn't this work?

find . -name '\*.java' -print

Well, now it's looking for a file that contains the \ character because the \ is in quotes. The only characters you can escape inside strong quotes are the ' and \ characters. Anything else is treated literally. So it's looking for a file that has \ in the name... and you probably don't have any.

What about this?

find . -name \'*.java' -print

Well, the ' character is now being escaped because it's preceded by a \ char -- so it'll be looking for a file with ' in the name. The wildcard is not escaped, so the shell will expand it into a list of filenames. The second ' character is treated as the start of a new quoted string -- so the shell won't even think you're done with the command. It'll think you still have more to type (until it finally encounters another ' character)

... anyway ...

If you want to prevent it from recursing into subdirectories, one somewhat simple solution is to do this:

find *.java -print

This tells the shell (not 'find') to produce a list of java files in the current directory. It then passes that list to the find command -- and that'll be all that find searches. (Assuming you don't have any directories that end in .java, it means it'll stay in the current directory.)

It's a bit of a kludge, really, but'll probably work. Unfortunately, the stupid IBM i versions of 'find' don't have a switch to prevent recursion.


On 5/14/2010 12:26 PM, Charles Wilt wrote:

Dennis,

I was testing the statement via direct entry into a QSH session. ie.
from the shell prompt.

Test recursive find:
cd /home/myuserid

find . -name \*.java -print
./GetInactiveCabinets.java
./testsub/GetInactiveCabinets.java
./testcmw.java


This worked:
find . \( ! -name . -prune \) -name \*.java -print
./GetInactiveCabinets.java
./testcmw.java

But this didn't
find . \( ! -name . -prune \) -name '\*.java' -print

Nor did this
find . \( ! -name . -prune \) -name \'*.java' -print

Just trying to understand why I don't have to quote the wildcard...

Charles

On Fri, May 14, 2010 at 10:48 AM, Dennis Lovelady<iseries@xxxxxxxxxxxx> wrote:

Not sure I quite understand, Charles. (Sorry.) Are you doing this via QSH
command or direct entry to the shell, or in a script or something else?

Can you provide an example that doesn't work for you, and I'll see if I can
determine what needs to be done to make it work?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Fear less, hope more,
eat less, chew more,
whine less, breathe more,
talk less, say more,
hate less, love more,
and all good things will be yours.
-- Swedish proverb

The thing is, when I quote the *.c...it doesn't find anything. Leave
it unquoted and it does.

Is the shell seeing the \ as an escape charactor and thus the quotes
are not needed to prevent the shell from expanding the wildcard
perhaps?

What would I need if the pattern I'm actually looking for looks like
???? .fin.cis0000.staf.input01.????????.zip

Charles

On Fri, May 14, 2010 at 9:44 AM, Dennis Lovelady<iseries@xxxxxxxxxxxx>
wrote:

I forgot about prune. I believe the below will work in most cases

(but do

read the next paragraph). You are correct: the * in *.c would need

to be

escaped or enclosed in quotes. It'll work if there's no *.c file in

the

current directory (the one from which the command is issued) but

that's

dicey.

The thing I don't like about -prune is that the documentation I've

seen is

sketchy and ambiguous. So are the results. For example, I would

expect

this to return a list of all files in the current directory:
find . -prune
but it won't. Likewise, this returns an empty list except the lone

dot:

find . -name "*" -prune

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Some see the problem in every opportunity, some see the opportunity

in

every problem."
-- Kevin Cowling

I found this message on the net....

cd to the directory in question so that you can use . in the find
command,
then, for example,
find . \( ! -name . -prune \) -name \*.c -print

It seems to work, but I don't understand why *.c doesn't need to be
quoted....

Also, it seems that this doesn't find recursively, but I'm not sure

if

the shell isn't processing the wildcard....
find /mypath/*.txt

I need a better understanding of how shells and unix type utilities
work! :)
Anybody know a good manual?

Thanks,
Charles




On Fri, May 14, 2010 at 8:44 AM, DrFranken<midrange@xxxxxxxxxxxx>
wrote:

Charles,

Sadly there IS a switch however it's not supported by find in

PASE.

Worked through that myself just yesterday.

- Larry

Dennis,

Is there a switch I'm not seeing to make find non-recursive?

Thanks,
Charles

On Thu, May 13, 2010 at 11:54 AM, Dennis

Lovelady<iseries@xxxxxxxxxxxx> wrote:

What's the currently recommended way of purging IFS files by

date?

I found an old utility from Scott Klement, that comes really

close

to

perfect. The only issue is it purges everything in a given

directory,

I'd like to be able to pass a wildcard file name. I haven't

look

at

it in detail, but I suspect that modifying it to process file

name

wildcards would be non-trivial. Then again, perhaps not if I

can

find

an good example of comparing a wild card value to another

string,

(regex perhaps? but might be overkill).

find /my_path -mtime ${PURGE_DAYS} -name "${WILDCARD_NAMES}" -

exec

rm {} \;

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Inanimate objects are classified scientifically into three

major

categories

- those that don't work, those that break down, and those that

get

lost."

-- Russell Baker

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.