CRON-Job / Shell-Skript deleting special files

Just I'm trying to find script, which will do the following job:

  1. as a CRON-Job it shoult
    a) delete files which will be either older than 24 hours or
    b) all files within
    a) a directory deleting recursive
    b) only a special directory.
  2. write an error-/Delete_log or not.

lets say, the shell-skript will be names as df.sh
so it would be executed with three parameters:

  df.sh  j j n

this will be submitted as Parameters and - as far as I know?? - could be read with:

case $1 in
[jJ]) VAR1=1; export VAR1;;
[nN]) VAR1=0; export VAR1;;
*) echo "ERROR1"; PERROR=1; export PERROR;;
esac
case $2 in
[jJ]) VAR2=1; export VAR2;;
[nN]) VAR2=0; export VAR2;;
*) echo "ERROR2"; PERROR1=1; export PERROR;;
esac
case $3 in
[jJ]) VAR3=1; export VAR3;;
[nN]) VAR3=0; export VAR3;;
*) echo "ERROR3"; PERROR2=1; export PERROR;;
esac

why didn't it work??

When using
df.sh j jn j
the errormessage for Var2 will be shown

when using
df.sh jj jj jj
all errormessages will be shown

When useing
df.sh j j j
no errormessages, but the Variables are not set! WHY??

Any help would be nice.

thanks
Manfred

In your case statements, [jJ] is searching either for a "j" or a "J" .. the same with [nN].

$1="j" , $2="jn" , $3="j"
"jn" doesn't equal "j" , "J" , "n" or "N", so you get the error.

You'd need to actually test for "jn"...

case $2 in
[jJ]) do something;;  # if $2="j" or $2="J"
[nN]) do something;;  # if $2="n" or $2="N"
jn) do something;;    # if $2="jn"
jj) do something;;    # if $2="jj"
*) echo "ERROR2"; PERROR1=1; export PERROR;;
esac

Thanks,

that's what I say.
Doing it with wrong parameters like
df.sh j jj n
this will show, that $2 is a wront parameter, because only j or J would be accepted .

But the thing
.... doing something didn't work.

lets say, I'll getting the first j - which would say set VAR1 to 1.
This woun't work with this part. Why??

Thanks
Manfred

What makes you think it's not working? Are you getting a specific error message? Are you just not seeing anything on the screen? The export command isn't going to show you anything... if you want some visual confirmation that VAR1 is set, then use a line of code like "[jJ]) VAR1=1; export VAR1; echo $VAR1;;"

Hi,
that's right.
What makes me worring:
Theres - of course - nothing on screen, but the VAR1..VAR3 are not set. Just looking with SET-Command you won't find them. Therefor I thought, something wrong the Syntax, the script is running on ksh might be here something wrong??

That's my problem.

thanks
Manfred

Try placing the SET command in your script somewhere so you can see what variables are set during execution... the variables should be set while the script is running. They are unset when the script ends.

very ugly, but it works!
Having to echo first the parameters, than within statement controlling with echo too and it works. But - please - don't aks why??

But even it works now.
Just btw -
to delete files from an directory comming with
... find <path> -ctime 0 -exec rm -i {}\;

works fine up to that point, when not deleting recursive beginning on specified path.

But what to do, when only deleting the files within this directory and not with subdirs??
This would .- perhaps - work, but after path you need to specify - as fas as I know - something else for the grep, otherwise it would be the same as without grep.
Any possibility - perhaps comming on to "\" counting??

.... find <path> -ctime 0 | greb <path> ??? -excec .....;

Thanks in advance for your help up to now.

Manfred

I'm having some trouble understanding you, so I'm not sure if this is what you're asking. If you don't want "find" to look into subdirectories, you can either try using -prune or -level 0.

Read the man page for "find" to learn more about the different parameters.

Thanks
I'll try it. But I've never heard - even a jungster with UNIX - about level 0. Will try and can't be worser than that find what I have.

tnks, Manfred

HI,

THANKS .... THANKS

It works with -prune but it didn't find level 0. Never mind.
Just what I want works and that's up to your help.
Thanks again
Manfred